[Bug] ACL invalid policy accepted

[lethedata]

Is this a support request?

• [x] This is not a support request

Is there an existing issue for this?

• [x] I have searched the existing issues

Current Behavior

Running policy check with invalid src/dst returns "Policy is valid"

Expected Behavior

Policy check fails and returns an error.

Steps To Reproduce

1. Create acls.jsonc policy using the configuration below
2. Run policy check against bad acls.jsonc file: headscale policy check -f ./acls.jsonc
3. Returns Policy is valid

{
    "acls": [
        { "action": "accept", "BAD": ["FOO:BAR:FOO:BAR"], "BAD": ["BAD:BAD:BAD:BAD"] }
      ]
}

Environment

- OS: Fedora CoreOS 42.20250427.3.0
- Headscale version: v0.26.0

Runtime environment

• [x] Headscale is behind a (reverse) proxy
• [x] Headscale runs in a container

Debug information

{
    "acls": [
        { "action": "accept", "BAD": ["FOO:BAR:FOO:BAR"], "BAD": ["BAD:BAD:BAD:BAD"] }
      ]
}

[Codelica]

Please just keep one thing in mind if the plan is to validate all input properties on the ACL. A few months ago @goodieshq and I noticed that additional properties could be added to an ACL entry which were stored and ignored. This actually allows for some very nice/powerful UI state to be stored for the Headscale-Admin GUI project. For example ACL rules can be named, UI collapse state stored, etc. Currently this is a single property tree named #ha-meta on the ACL entry to keep it isolated. Perhaps when it comes to validation, property names that start with # could be ignored for metadata/comments? Please :)

[kradalby]

This is interesting. I am not very concerned that the example validates as a valid policy. The most annoying would be mistyped versions of the correct fields that are not caught, srd vs src for example.

The "use the policy as JSON storage" is quite funny too, I suppose that is relatively fine.

We can do what @Codelica suggests and reserve things prefixed with #, and then validate all the other fields to get something in between, both better validation, but also some flexibility, without letting it go "too far".

[lethedata]

This is interesting. I am not very concerned that the example validates as a valid policy. The most annoying would be mistyped versions of the correct fields that are not caught, srd vs src for example.

A mistyped dnt over dst typo is actually what lead to this issue. It was originally going to just be about the typo being accepted but after messing around I realized there was no validations allowing the above example to return valid. I used this unrealistic example as it very obviously shows what is going on at a glance without taking a second to locate the non-obvious typo.