Re: kadmin ignoring target column ?
Laura Smith <[email protected]>
| Newsgroups | gmane.comp.encryption.kerberos.general |
|---|---|
| Message-ID | <FiT1mVCBUdyTiFD2gaIHStn5I8rkUq5DHd-xHQ3xkW_3H7J5mokt72teQeWojs4KD2IgfEgzlFrG_9b3bDgZnqZHCozNoFyQqXW0z_5MNvc=@protonmail.ch> |
Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, January 12, 2020 10:48 PM, Greg Hudson <[email protected]> wrote: > On 1/12/20 2:01 PM, Laura Smith wrote: > > 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. Am aware of the list ordering requirement, and to that extent the ACL entry in question was quite deliberately placed at the top. > > With the current sources, if I do "make testrealm" and then change the > first line of testdir/acl to read: > > user/[email protected] 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/[email protected]; defaulting to no policy Principal "nfs/[email protected]" created. kadmin: addprinc -pw pw test/test No policy specified for test/[email protected]; defaulting to no policy add_principal: Operation requires`add'' privilege while creating > "test/[email protected]". > (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.) > admcil nfs/@KRBTEST.COM, are you saying I should not be putting the wildcard asterisk after nfs/ ? > 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. Running 1.17 on Alpine Linux 3.10.3 ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos