[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: yet another ACL question
Hi,
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
--
Dieter Kluenter | Systemberatung
Tel:040.64861967 | Fax: 040.64891521
mailto: dkluenter(at)dkluenter.de
http://www.avci.de