[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#3491) ACL and 'operational' (generated) attrs issue
- To: openldap-devel@OpenLDAP.org
- Subject: Re: (ITS#3491) ACL and 'operational' (generated) attrs issue
- From: "Pierangelo Masarati" <ando@sys-net.it>
- Date: Tue, 18 Jan 2005 10:41:33 +0100 (CET)
- Importance: Normal
- In-reply-to: <200501161030.j0GAU4HA066390@boole.openldap.org>
- References: <200501161030.j0GAU4HA066390@boole.openldap.org>
- User-agent: SquirrelMail/1.4.3a-1
[redirected to -devel from -its]
A workaround for entryDN would be to detect it in acl_mask() and use the
entry's DN instead. In principle, we could even move the entry's DN into
an Attribute type that holds the entryDN, and make sure it's always listed
first in the entry. Then the macros e_name and e_nname could point to
e_attrs->a_vals[0] and e_attrs->a_nvals[0].
p.
> Full_Name: Pierangelo Masarati
> Version: HEAD/2.3 (suspect earlier)
> OS: irrelevant
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (151.29.240.57)
>
>
> An ACL set like
>
> access to attrs=userPassword
> by * auth
>
> access to *
> by dnattr=entryDN read
> by * search
>
> fails with insufficient access even if a bound user searches its own
> entry.
> This occus because access checking occurs with and entry that doesn't
> contain
> the generated attributes. of course, using "self" instead of
> "dnattr=entryDN"
> fixes the problem, however, in some cases the "entryDN" as well as other
> generated attributes may be useful in ACLs as well as in other places
> where
> generated data related to an object may need to be dereferenced.
>
> p.
>
>
>
--
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497