Re: [LDAP-SOFTWARE] ACLand regex (matching self)

[Peter Marschall <peter.marschall@mayn.de>]

Hi,

On Tuesday 04 March 2003 13:58, Ace Suares wrote:
> > AFAIK there is only one object that seems to be hidden:
> > The tree root, with the name "" (the empty string between the quotes)
> > This object is not hidden, but has simply an empty name which
> > makes it hard to find.
>
> Thanks to previous posts, I got that far already.
> What I coudn't find out from the docs was:
>
> a. if you DON'T specify any access rule for the empty DN (the RootDSE)
> that other ACL's don't work anymore.
> Example:
>
> access to dn="app=qwido"
>   by dn="app=qwido"
>
> gives access to the ENTIRE tree under app=qwido.

This may be because "access to dn" is the same as
"access to dn.regex". Have you tried "access to dn.exact" ?
(I had to look it up at: http://www.openldap.org/faq/data/cache/451.html )

> This, I still don't understand completely.
> AFAIK, this means that a subschemaEntry MAY be part of the tree, even if I
> didn't add it. I can't understand that !

Yes, the DN specified by the value of the subschemaEntry attribute of the
rootDSE exists even if you did not create it. You cannot even create it,
since it is automatically there.
IIRC the schema is a requirement for LDAPv3. It tells clients, that want to
know, what objectclasses are known to the server, what attributes are allowed
and/or required for the objectclasses, whcick syntax an attribute has.
For example, in the schema you find that the inetOrgPerson objectclass
requires attributes sn and  cn, and that it allowes attributes called mail, 
... And it tells which syntax to use for mail, sn, cn, and whether it is 
allowed to add more than value for a specific attribute.
This is very useful for generic clients that use this information to
create the correct input/output fields for the interface.

> Also, by not specifying explicit access to these (apparently
> server-dependend) dn's, the ACL's don't work as expected. For instance, GQ
> dind't allow me to browse the schema's - what's worse, it didn't let me add
> specific objects that rely on self-made schema's, because it couldn't read
> those schema's.
The entries (cn=SubSchema) may be server dependent, but the way to find
them is not (subSchemaSubEntry attribute of rootDN).
This is defined in the RFCs for LDAPv3.

> Furthermore, let's say I have a list of 'unexpected' dn's obtained by the
>
> command you recommend:
> > The most famous examples are the subschemaSubentry attribute which
> > contains the the DN of the schema and the namingContexts attribute
> > that contains the names of the top level nodes of your directory
> > branches.
> >
> > ldapsearch -b "" -s base '(objectclass=*)' +
> > gives you the information required.
>
> what kind of access do they need ? search, compare ? or write ? or read ?

Clients need to know the informations in the rootDSE.
You should have read access (which includes compare)
to the rootDSE and to the schema.
Since this information can currently only be changed 
using slapd.conf write may not hurt , but this may change
in the future.

For the branches given in namingContexts, the rights depend on
your needs. Some parts may be read only, some read-write,
some only write and authenticate (i.e. passwords ;-)

Peter
-- 
Peter Marschall     |   eMail: peter.marschall@mayn.de
Scheffelstraße 15   |          peter.marschall@adpm.de
D-97072 Würzburg    |   Tel:   +49 931 14721
PGP: 0BB1 04A3 0FB0 E27F 8018 52BA A286 7B23 9C22 2C83