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. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
