Issue 4587 - selfwrite access is broken
Summary: selfwrite access is broken
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-13 01:17 UTC by Howard Chu
Modified: 2014-08-01 21:06 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Howard Chu 2006-06-13 01:17:00 UTC
Full_Name: Howard Chu
Version: 2.3/HEAD
OS: 
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (24.126.120.178)
Submitted by: hyc


An ACL of the form
  access to dn.subtree="ou=groups,dc=example,dc=com" attr=member by * selfwrite

is intended to only allow users to add/delete their own DN to the target
attribute. Currently it allows any DNs to be modified.

Comment 1 Howard Chu 2006-06-13 01:33:59 UTC
changed notes
changed state Open to Test
moved from Incoming to Software Bugs
Comment 2 Ralf 2006-06-14 14:27:13 UTC
On Tuesday 13 June 2006 03:17, hyc@openldap.org wrote:
> Full_Name: Howard Chu
> Version: 2.3/HEAD
> OS:
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (24.126.120.178)
> Submitted by: hyc
>
>
> An ACL of the form
>   access to dn.subtree="ou=groups,dc=example,dc=com" attr=member by *
> selfwrite
>
> is intended to only allow users to add/delete their own DN to the target
> attribute. Currently it allows any DNs to be modified.
Current HEAD code still allows the following LDAPMod e.g. for user
"uid=user,ou=people,dc=example,dc=com"

dn: cn=testgroup,ou=groups,dc=example,dc=com
add: member
member: uid=user,ou=people,dc=example,dc=com
member: uid=otheruser,ou=people,dc=example,dc=com

-- 
Ralf

Comment 3 Howard Chu 2006-06-26 12:30:48 UTC
On Tuesday 13 June 2006 03:17, hyc@openldap.org wrote:
>> Full_Name: Howard Chu
>> Version: 2.3/HEAD
>> OS:
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (24.126.120.178)
>> Submitted by: hyc
>>
>>
>> An ACL of the form
>>   access to dn.subtree="ou=groups,dc=example,dc=com" attr=member by *
>> selfwrite
>>
>> is intended to only allow users to add/delete their own DN to the target
>> attribute. Currently it allows any DNs to be modified.
>>     
>
>   
The selfwrite mode is still broken for sets.
   access to <foo> by set=<bar> selfwrite
gives full write access.

-- 
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  OpenLDAP Core Team            http://www.openldap.org/project/

Comment 4 Ralf 2006-06-27 09:43:18 UTC
On Monday 26 June 2006 14:31, hyc@symas.com wrote:
> On Tuesday 13 June 2006 03:17, hyc@openldap.org wrote:
> >> Full_Name: Howard Chu
> >> Version: 2.3/HEAD
> >> OS:
> >> URL: ftp://ftp.openldap.org/incoming/
> >> Submission from: (NULL) (24.126.120.178)
> >> Submitted by: hyc
> >>
> >>
> >> An ACL of the form
> >>   access to dn.subtree="ou=groups,dc=example,dc=com" attr=member by *
> >> selfwrite
> >>
> >> is intended to only allow users to add/delete their own DN to the target
> >> attribute. Currently it allows any DNs to be modified.
>
> The selfwrite mode is still broken for sets.
>    access to <foo> by set=<bar> selfwrite
> gives full write access.

Hm, I did some more checks. The following cases don't work as well

access to <foo> by group=<bar> selfwrite

and 

access to <foo> by peername=<bar> selfwrite

both give full write access. To me it seems to be broken for almost every 
"who" clause apart "dn".

-- 
Ralf

Comment 5 Ralf 2006-06-27 13:34:44 UTC
On Tuesday 27 June 2006 11:43, rhafer@suse.de wrote:
> > The selfwrite mode is still broken for sets.
> >    access to <foo> by set=<bar> selfwrite
> > gives full write access.
>
> Hm, I did some more checks. The following cases don't work as well
>
> access to <foo> by group=<bar> selfwrite
>
> and
>
> access to <foo> by peername=<bar> selfwrite
>
> both give full write access. To me it seems to be broken for almost every
> "who" clause apart "dn".

I have just commited another set of changes in acl.c to HEAD. The orignial fix 
did the "selfwrite" check only if there was a "dn" or "realdn" pattern in the 
<who>. Now that check is done regardless of what other components are present 
in <who>.

Please review.

-- 
Ralf

Comment 6 Ralf 2006-06-27 14:44:32 UTC
On Tuesday 27 June 2006 15:35, rhafer@suse.de wrote:
> On Tuesday 27 June 2006 11:43, rhafer@suse.de wrote:
> > > The selfwrite mode is still broken for sets.
> > >    access to <foo> by set=<bar> selfwrite
> > > gives full write access.
> >
> > Hm, I did some more checks. The following cases don't work as well
> >
> > access to <foo> by group=<bar> selfwrite
> >
> > and
> >
> > access to <foo> by peername=<bar> selfwrite
> >
> > both give full write access. To me it seems to be broken for almost every
> > "who" clause apart "dn".
>
> I have just commited another set of changes in acl.c to HEAD. The orignial
> fix did the "selfwrite" check only if there was a "dn" or "realdn" pattern
> in the <who>. Now that check is done regardless of what other components
> are present in <who>.
>
> Please review.

Btw, test006-acls currently fails in head. The failing test tries to modify a 
"uniquemember" Attribute with selfwrite privileges. "uniqueMember" however 
does not have DN syntax but is "name an optional uid". What would be the 
correct fix or isn't this a bug at all? 

-- 
Ralf

Comment 7 Howard Chu 2006-07-09 08:00:59 UTC
rhafer@suse.de wrote:
> On Tuesday 27 June 2006 15:35, rhafer@suse.de wrote:
>> On Tuesday 27 June 2006 11:43, rhafer@suse.de wrote:
>>>> The selfwrite mode is still broken for sets.
>>>>    access to <foo> by set=<bar> selfwrite
>>>> gives full write access.
>>> Hm, I did some more checks. The following cases don't work as well
>>>
>>> access to <foo> by group=<bar> selfwrite
>>>
>>> and
>>>
>>> access to <foo> by peername=<bar> selfwrite
>>>
>>> both give full write access. To me it seems to be broken for almost every
>>> "who" clause apart "dn".
>> I have just commited another set of changes in acl.c to HEAD. The orignial
>> fix did the "selfwrite" check only if there was a "dn" or "realdn" pattern
>> in the <who>. Now that check is done regardless of what other components
>> are present in <who>.
>>
>> Please review.
> 
> Btw, test006-acls currently fails in head. The failing test tries to modify a 
> "uniquemember" Attribute with selfwrite privileges. "uniqueMember" however 
> does not have DN syntax but is "name an optional uid". What would be the 
> correct fix or isn't this a bug at all? 
> 
Oops. I forgot you'd already noted this, please ignore my other email.

At the moment I feel too lazy to worry about this for this syntax, 
there's no legitimate use for it in LDAP. There's hardly any use for it 
in X.500 really, the "uid" part is so awkward... So at the moment I 
don't consider that a bug.

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc
   OpenLDAP Core Team            http://www.openldap.org/project/

Comment 8 Howard Chu 2006-07-09 08:14:02 UTC
hyc@highlandsun.com wrote:
> rhafer@suse.de wrote:

>>> Please review.
>> Btw, test006-acls currently fails in head. The failing test tries to modify a 
>> "uniquemember" Attribute with selfwrite privileges. "uniqueMember" however 
>> does not have DN syntax but is "name an optional uid". What would be the 
>> correct fix or isn't this a bug at all? 
>>
> Oops. I forgot you'd already noted this, please ignore my other email.
> 
> At the moment I feel too lazy to worry about this for this syntax, 
> there's no legitimate use for it in LDAP. There's hardly any use for it 
> in X.500 really, the "uid" part is so awkward... So at the moment I 
> don't consider that a bug.
> 
Hm, I take that back. Currently we check for the NAMEUID_SYNTAX when 
parsing a dnattr ACL, so there's obviously an expectation that this 
should be handled as a DN.

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc
   OpenLDAP Core Team            http://www.openldap.org/project/

Comment 9 Kurt Zeilenga 2006-08-22 06:11:40 UTC
changed notes
Comment 10 Howard Chu 2006-10-07 19:48:21 UTC
changed notes
changed state Test to Closed
Comment 11 Howard Chu 2009-02-17 05:18:47 UTC
moved from Software Bugs to Archive.Software Bugs
Comment 12 OpenLDAP project 2014-08-01 21:06:44 UTC
fixed in HEAD/re24/2.3.25