Fix create token sudo non-root namespace check

[michelvocks]

The SudoPrivilege check expects a path without a namespace prefix since it calls AllowOperation which is already namespace-aware and checks by default the full context namespace path: https://github.com/hashicorp/vault/blob/master/vault/acl.go#L342

The consequence is that you have to define a separate policy to apply sudo rights for the token/create endpoint e.g.:

This policy allows you to create tokens but only without sudo-rights:

vault policy write -ns=test pol1 -<<EOF
path "auth/token/*" {
    capabilities=["sudo", "create", "update", "delete", "list", "read"]
}
EOF

You can only get sudo-rights by explicitly specifying the namespace:

vault policy write -ns=test pol1 -<<EOF
path "auth/token/*" {
    capabilities=["sudo", "create", "update", "delete", "list", "read"]
}

path "test/auth/token/*" {
    capabilities=["sudo", "create", "update", "delete", "list", "read"]
}
EOF

We should add additional tests on the enterprise side to make sure that this change doesn't introduce other side effects.

[jefferai]

I think there is still a weird case but I'm not sure we need to/should fix it.

Imagine you have a token in ns1/. We, for some reason, are checking the path ns2/foo/bar. This will cause the path that is eventually checked to be ns1/ns2/foo/bar. This is correct from the perspective of AllowOperation, but is potentially incorrect from the perspective of whether SudoPrivilege should be checking a full path or not. So far what gets passed in is a full path.

Possibly the actual correct thing to do is to not do anything at all. Require what comes in to be a full path and validate it against a context with no namespace whatsoever. This will mean AllowOperation will run against a full path -- which is what it's trying to do by attaching the context namespace to the incoming path.