v8 acl enforcement, ACLs/tokens, and service deregistration

[r0ps3c]

Running/testing in 0.7.5 and HEAD as of a day or so ago (cf1b325), I'm hitting a couple of issues that seem related regarding service deregistration, agent vs catalog synchronization, and ACLs.

My understanding based on the documentation (acl and agent configuration) is that the agent-token is/should be used for agent->catalog operations, and the acl-token is (effectively) used instead of 'anonymous' when the caller/client does not supply their own token (i.e. for client -> agent).

Running with this configuration (i.e. no acl_token):

{
        "acl_master_token":"<master_token>"
        "acl_datacenter":"dc1",
        "acl_default_policy":"deny",
        "acl_down_policy":"deny",
        "acl_enforce_version_8":true,
        "acl_agent_token":"<agent_token>"
} 

where master_token policy is as default, acl_agent_token policy is:

node "" { policy = "write" }
service "" { policy = "write" }
agent "" {policy = "write"}

and anonymous is

service "" { policy = "read" }

I see two connected issues when services are deregistered:

• based on the documentation and a few other places in the code (e.g. localstate.setSyncState and comments in the ACL checking functions), I would've expected acl_agent_token to be used for synchronisation from agent local state -> catalog, including HTTPServer.syncChanges, with all other tokens/checking being for client-side access control
• localState.RemoveService removes the service token (if any) at local.go, forcing the subsequent HTTPServer.syncChanges (in agent_endpoint.go) to use the anonymous or acl_token even if there was a service token with sufficient privileges to begin with

Consequently, I am seeing persistent desynchronization between the agent's view and the catalog when services are deregistered with the agent complaining that services cannot be deleted and synchronization is failing with messages similar to:

agent: cannot delete service
agent: failed to sync changes: Permission denied

My feeling is that the acl_agent_token should be being used for catalog operations, leaving the service token to be used/checked only by the client-facing functions, but would be curious if I am misunderstanding something and/or what configuration/policies need to be redone on my end.

Thanks

[slackpad]

Hi @r0p0s3c thanks for opening this issue. I think for this case since the service token was used for the registration it should also be used for the delete, so this sounds like a bug. Will take a deeper look here shortly.

[slackpad]

Hi @r0p0s3c if you can give master a try and see if that's working for you now we'd appreciate it!

[r0ps3c]

Thanks, this looks good to me