On Tue, 2013-03-12 at 18:31 +0100, Jan Cholasta wrote: > On 12.3.2013 18:01, Simo Sorce wrote: > > On Tue, 2013-03-12 at 17:31 +0100, Jan Cholasta wrote: > >> On 12.3.2013 17:24, Simo Sorce wrote: > >>> On Tue, 2013-03-12 at 17:02 +0100, Jan Cholasta wrote: > >>>> Why can't we set the bitfield (krbTicketFlags) directly? (There is an > >>>> ACI preventing that, I'm just wondering what is the reason for this.) > >>> > >>> If you tell me who 'we' is (as in what user would set it) I can tell you > >>> why it is/isn't possible. > >> > >> Why no IPA user (including admins) can set the attribute? > > > > I guess admins should be allowed to. > > > > Users can't, as ticket flags change the behavior of the principal in > > ways only admins should allowed to. (preauth required or not, AS > > requests disabled or not, etc...) > > Thanks. For normal users it's obvious, but it seemed a little bit > strange to disallow admins to set the flags. > > So, can the krbTicketFlags attribute be used internally in IPA plugins > to set/unset the flags, given that the ACI is changed to allow admins to > modify the attribute?
The problem is determining if all the flags can be set by the same set of admins or if we need to be able to delegate some of them. In the second case we have only 2 options: 1) break the flags out in multiple attributes so we can set separate ACIs 2) create a plugin that can intercept and filter modifications to the attribute so only the allowed flags are changed The first option has the problem that we are going to change the schema. The second option has the problem that the check will be less flexible than with regular ACIs (unless we use some sort of virtual ACI) and duplicates access control points. Anyway we need to find out if we really need fine grained access control per flags or not before wrapping our heads. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel