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

Re: yet another ACL question


Am Sam, 2003-09-13 um 04.50 schrieb Brian J. Murrell:
> On Fri, 2003-09-12 at 10:35, suomi hasler wrote:
> > Hi Brian
> Hi Suomi,
> > if you prohibit base read access to the directory (in your last ACL "by 
> > * none"),  you prohibit access to the schema and basic DIT information 
> > like e.g. namingContext.
> Indeed.  This is what I had gathered.  I was hoping my query here would
> yield some help in determining what "minimum" amount of read access I
> had to allow in order to allow access to that information.
> I prefer to not try to lock down information as it's added to the
> directory, but rather open it up as required.  The former is prone to
> security/information leaks.  The latter is just broken functionality
> with regard to new information until it is corrected.  Fail-safe as it
> were.
> It seems there is some information, protectable by ACLs that
> applications can read from the database that is not obvious to a
> directory administrator.  I was hoping somebody would shed light on that
> aspect.

Start slapd in debugging mode -d128. The log will show you something
like following excerpt

=> access_allowed: search access to "" "objectClass" requested
=> acl_mask: access to entry "", attr "objectClass" requested
<= check a_dn_pat: *
<= acl_mask: [1] applying read(=rscx) (stop)
> access_allowed: search access granted by read(=rscx)
=> access_allowed: read access to "" "entry" requested
 access_allowed: read access granted by read(=rscx)
=> access_allowed: read access to "" "supportedSASLMechanisms" requested
= acl_mask: [1] applying read(=rscx) (stop)
<= acl_mask: [1] mask: read(=rscx)
=> access_allowed: read access granted by read(=rscx)

An access clause like the following would solve your problems

access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read

Dieter Kluenter  | Systemberatung
Tel:040.64861967 | Fax: 040.64891521
mailto: dkluenter(at)dkluenter.de