[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Insufficient acces in some cases



Hi,

On Tue, Sep 18, 2018 at 11:21:07PM +0200, Clément OUDOT wrote:
> 
> 
> Le 18/09/2018 à 23:10, Ervin Hegedüs a écrit :
> > Hi,
> >
> > On Tue, Sep 18, 2018 at 10:34:55PM +0200, Clément OUDOT wrote:
> >>
> >> Le 18/09/2018 à 22:23, Ervin Hegedüs a écrit :
> >
> > olcAccess: {0}to attrs=userPassword,shadowLastChange
> >   by self write
> >   by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write
> >   by anonymous auth
> >   by * none
> > olcAccess: {1}to dn.subtree="ou=OU1,dc=service1,dc=bigcompany,dc=hu"
> >   by dn="uid=_srvuser2,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read
> >   by dn="uid=_srvuser3,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read
> >   by dn="uid=_srvuser4,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read
> >   by dn="uid=_srvproftpd,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read
> >   by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write
> >   by * none
> > olcAccess: {2}to dn.regex="ou=(comp1|comp2|comp3),dc=service1,dc=bigcompany,dc=hu"
> >   by dn="uid=_srvuser2,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read
> >   by dn="uid=_srvuser3,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read
> >   by dn="uid=_srvuser4,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read
> >   by dn="uid=_srvproftpd,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read
> >   by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write
> >   by * none
> > olcAccess: {3}to dn.subtree="dc=bigcompany,dc=hu"
> >   by dn="uid=_srvuser3,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read
> >   by dn="uid=_srvuser4,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read
> >   by dn="uid=_srvproftpd,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read
> >   by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write
> >   by * none
> > olcAccess: {4}to *
> >   by self write
> >   by anonymous auth
> >   by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write
> >   by * none
> >
> >
> >> Are you sure that a user can modify userPassword and sambaNT/LM password
> >> attributes?
> > yes, I'm sure.
> >
> > The NT/LM password attribures aren't named any place, the
> > userPassword is, but all user can modify its own - see ACL's above.
> 
> No, the olcAccess {3} deny all access inside dc=bigcompany,dc=hu, the
> rule {4} is never evaluated.

well, you're right - but then how does it works for other users?

It's too late here (.hu), I'll check it again tomorrow.

 
> > And as I wrote in first mail, the simple "ldapmodify" works as
> > well.
> 
> Do you test to modify only userPassword attribute? Or your modification
> is also on Samba attributes?

no, I just put the userPassword attribute,
 
> > And more important, the other users under the same OU can change
> > their own userpassword/nt/lm password attributes through PHP.
> 
> I don't how, because your ACL allow only userPassword modification for
> 'self'.

yes, that's very interesting.

and one important thing: if this issue is a "simple" ACL problem,
why logs slapd an interesting lines (one char in a line)? Why
just deny the access...?
 
> > The service user (_srvuser1) also can modify (through PHP), but I'ld
> > like to use as the logged user modify its own passwd.
> >
> 
> I think you should merge your ACL like this:
> 
> olcAccess: {3}to dn.subtree="dc=bigcompany,dc=hu"
>   by dn="uid=_srvuser3,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu"
> read
>   by dn="uid=_srvuser4,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu"
> read
>   by
> dn="uid=_srvproftpd,ou=Users,ou=_srv,dc=service1,dc=bigcompany,dc=hu" read
>   by dn="uid=_srvuser1,ou=Users,ou=_srv,dc=hu" write
>   by self write
>   by * none

thanks, as I wrote, it's too late here to focus the problem, I'll
check it tomorrow with fresh brain :).


Thanks for all,


a.