On Fri, 2014-01-10 at 15:14 -0500, Nathaniel McCallum wrote: > On Thu, 2014-01-09 at 17:37 -0500, Simo Sorce wrote: > > On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote: > > > This patch is independent from my patches 0028-0031 and can be merged in > > > any order. > > > > > > This patch has a bug, but I can't figure it out. We need to set > > > nsslapd-access-userattr-strict on cn=config to "off". > > > > Uhmm what is the effect on ACL evaluation of changing this boolean ? > > I can;t figure out from your commit not from 389ds commit what exactly > > changes and how it impacts the security of the directory. > > > > I ask because I was planning on using userattr to protect some > > operations in the password plugin but was waiting due to bug: > > https://fedorahosted.org/389/ticket/47571 which is beeing resolved. > > > > I want to make sure your change won't change what this ACIs would allow. > > > > Is this option simply allowing the use of add/delete ACIs to be > > specified in conjunction with userattr, so that a user can add an attr > > only if it contains its own DN ? > > > > Will it allow the user to add multiple values to the same attr as long > > as one of the is the userDN ? O will it restrict that case ? > > > > (I know that ipaTokenOwner is a single-value attribute, but the > > mechanism you are enabling here is general, and I want to be sure of > > what the semantics are) > > After testing, it was determined that the 389DS patch #47653 does in > fact permit addition if any of the multi-valued attributes match the > condition. This is definitely problematic. > > After discussion today with nkinder, simo, nhosoi, we agreed to > roll-back patch #47653 and find an alternate approach. This also > invalidates patch freeipa-npmccallum-0032. Simo will follow up this > email with an alternate proposal.
Sorry for the delay, my proposal is to add a new keyword to the ACI system: selfattr selfattr is similar to userattr + #userdn, the syntax is simply: (selfattr=attrname) attrname is the name of the attribute that will be tested by the ACI evaluator, and the semantics combined with the various allow flags are the following: allow add: an entry can be added if and only if attrname = userDN where the user DN is the authenticated user DN. Furthermore the only value (is attrname is multivalued) allowed is again userDN allow delete: an entry can be deleted only if attrname has exclusively one value, the DN of the authenticated user For the write,read,search operation I am not sure we really need a special syntax, maybe we should actually disallow the combination. If we allow it we may (or not) want to have the following behavior: allow write: the only value that can be added to or removed from attrname is the authenticated userDN allow read: the entry can be searched but the only value returned for attrname is that of the authenticated userDN if present allow search/compare: the entry can be searched only if attrname contains the authenticated userDN I suspect these 3 behavrios can be obtained with different syntaxes too, for example using targeattr/targetattrfilter, in that case, maybe it is better to just restrict selfattr to be valid with add/delete operations for now. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel