On 1/12/20 2:01 PM, Laura Smith wrote:
> I am trying to create a suitably restricted user for use with configuration
> automation (SaltStack ). My line looks like the following :
>
> saltstack/ad...@example.com ADMCIL nfs/*@EXAMPLE.COM
The man page says:
If the character is *upper-case*, then the operation
is disallowed. If the character is *lower-case*, then the operation
is permitted.
Since all of the permission bits are in uppercase, that line should
grant no permissions to saltstack/admin. When I test with a similar
line it doesn't appear to grant add permissions for any principals. Is
there a previous line that matches the client saltstack/admin, and
grants full add permissions? kadmind stops when it finds the first ACL
line matching the client and target; it doesn't continue on to look for
a more specific match.
With the current sources, if I do "make testrealm" and then change the
first line of testdir/acl to read:
user/ad...@krbtest.com admcil nfs/*@KRBTEST.COM
then I get the expected results for user/admin:
kadmin: listprincs
get_principals: Operation requires ``list'' privilege while
retrieving list.
kadmin: addprinc -pw pw nfs/test
No policy specified for nfs/t...@krbtest.com; defaulting to no policy
Principal "nfs/t...@krbtest.com" created.
kadmin: addprinc -pw pw test/test
No policy specified for test/t...@krbtest.com; defaulting to no policy
add_principal: Operation requires ``add'' privilege while creating
"test/t...@krbtest.com".
(It turns out that operations with no target principal, including
listprincs, fail if there is any target pattern for the entry besides
"*". This isn't really documented.)
Also, what version of krb5 is running on the KDC? The kadmind ACL code
changed substantially in 1.16 (though it shouldn't have affected this
behavior), so if you're running an earlier version than that I might be
able to re-test with older code.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
