On 01/08/2014 04:19 PM, Simo Sorce wrote: > On Wed, 2014-01-08 at 15:49 +0100, Petr Viktorin wrote: >> On 01/08/2014 03:43 PM, Simo Sorce wrote: >>> On Wed, 2014-01-08 at 09:19 -0500, Simo Sorce wrote: >>>> On Wed, 2014-01-08 at 13:42 +0100, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> I'm working on exposing the krbPrincipalExpiration attribute in the CLI >>>>> (https://fedorahosted.org/freeipa/ticket/3306). However, this attribute >>>>> is exempted from the default ACL "Admin can manage any entry" >>>>> (install/share/default-aci.ldif +8). >>>>> >>>>> Now, we have several options: >>>>> 1.) remove it from blacklisted options in "Admin can manage any entry" ACL >>>> Nope, it was excluded on purpose, to prevent admins from playing with >>>> it. >>> OOOk and maybe If I stop reading "Password" when I see "Principal" I >>> would make more sense :-( >>> >>>>> 2.) create a new permission that allows writing to this attribute (i.e. >>>>> Modify Kerberos principal expiration) >>>> Yep, this sounds right. >>>> >>>>> 3.) add this attribute to a existing permission (Modify users seems like >>>>> the best candidate, however, the attribute does not really fit even there) >>>> Nope, needs to be explicit for auditing purposes that admins are able to >>>> violate the password policies of users by changing their expiration >>>> date. >>>> >>>>> I see that the the approach 1.) was taken with the krbTicketFlags >>>>> attribute in the past (install/updates/60-trusts.update +38). >>>> Yes, however I think this too should be probably explicit and have its >>>> own permission with the new permission framework. >>>> >>>>> What would be the best approach here? >>>> I say 2. >>> Given this is "Principal"'s expiration, I amend my suggestion. >>> >>> I say you can choose either 2 or 3. The *Account Expiration* (which is >>> what really this attribute controls) is clearly a user attribute and it >>> is not strictly necessary to have a separate permission. >>> However it is not a bad idea either. I think there may be cases when >>> some administrative process wants to allow admins to modify users, but >>> not let them extend a user account lifetime. The account lifetime may be >>> something that is controlled by an HR department and should not be >>> modifiable by all admins. >> How rare would this case be? We'll have manageable permissions, it >> should be easy to exclude the attribute and add a separate permission >> for it. > Right which is why I say 2 or 3, I do not have a strong preference, if > it is a hassle to create a new permission now, feel free to fold into > the std modify users permission for now. > > Simo. > Maybe the approach we should take is both #1 and #2. Not taking the #1 doesn't make sense for consistency's sake and reasons Martin mentioned (we do not prevent admin user for doing this anyway, just make it more complicated).
For fine-grained permission management, we can create new permission/privilege/role, and that's #2. This can be part of the current permission work, right? Tomas _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
