kadmin ignoring target column ?

[Greg Hudson]

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/admin at 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/admin at 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/test at KRBTEST.COM; defaulting to no policy
    Principal "nfs/test at KRBTEST.COM" created.
    kadmin:  addprinc -pw pw test/test
    No policy specified for test/test at KRBTEST.COM; defaulting to no policy
    add_principal: Operation requires ``add'' privilege while creating
"test/test at 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.