[Fwd: Re: Another approach to a previous question]

["Pierangelo Masarati" <ando@sys-net.it>]

> =)
>
> Previously I asked if there was a way to limit searches to exact
matches... so for instance you could search for
> printer-name=blar,ou=private,ou=printers,dc=ncsu,dc=edu but could not
search through ou=private,ou=printers,dc=ncsu=dc=edu... and the answer
was no.  =)
>
> For a different approach to this issue, I already have a tree called
ou=hosts,dc=ncsu,dc=edu.  This has host specific "configuration" type
information.  Currently, it only has what groups are allowed and not
allowed into the machine.  I was going to add printers to this, so you
can assign printers based off their entry in LDAP.  So lets pretend I
have an entry called:
> cn=skippy.unity.ncsu.edu,ou=hosts,dc=ncsu,dc=edu
> and it has:
> ncsuAssignedPrinter: dhl-2413-1
> ncsuAssignedPrinter: dhl-2413-2
> ncsuAssignedPrinter: dhl-2413-color1
> ncsuAssignedPrinter: dhl-2413-private-printer
>
> Is there any way I could limit access to the private printer tree based
off that?  In other words, "unless you are coming from skippy, you don't
get to see the entry for dhl-2413-private-printer" in
> ou=private,ou=printers,dc=ncsu,dc=edu.  Something like:
>
> access to
> dn.regex="printer-name=(.*),ou=private,ou=printers,dc=ncsu,dc=edu
>  	by (host, where host has $1 listed in it's ncsuAssignedPrinter)

It is unclear (at least to me) what are the terms of the problem.

When designing ACLs, one has to make it very clear what the terms
of the problem are.

So: what's the <who>, i.e. what's the entity that should be allowed to
gain access privileges?  It's what you're calling "... unless you're
coming from skippy...", so I guess you want to design a <who> based on the
"domain" or "peername" of the requester.

On the other hand, you want to write an ACL where values from the target
(the <what> clause), and significantly a portion of its RDN, is compared
to a value in the accessor's (the <who> clause) entry, i.e. data in the
entry that is requesting access.

OpenLDAP's ACLs apply to the target, i.e. the <what> clause and can play
with its attribute values either by means of the

    "attrs=<attrlist>[ val=<value>]"

mechanism, or by the

    "filter=<filter>"

mechanism.

One exception are sets, which currently are almost undocumented, except
for  http://www.openldap.org/faq/data/cache/452.html (to my knowledge). 
Unfortunately sets cannot play with the "domain" or "peername"
information, so you need to combine both.  I'm not an expert set
programmer, so I won't help you in that.

If I get your problem right, you have:

- A printer entry

- A host entry, which lists allowed printers

and your need is:

- allow requests originating from host to access entries whose naame
matches the attributes listed in that host's entry.  Wow, that's really
indirect.

I guess the only solution at present would be to hack the "sets" code to
allow the use of the "domain" information along with "this" and "user". 
This shouldn't be too difficult, but I wouldn't consider it an easy hack
in principle, and I don't know sets well enough.  In that case, a rule
could look like:

access to dn.regex="^cn=([^,]+),ou=printers,dc=example,dc=com$"
 by set="this.cn & [cn=$d,ou=hosts,dc=example,dc=com].ncsuAssignedPrinter"
read

where "$d" could be a meta-replacement, in regex style, for the "domain"
info (you could use "$p" for the peername info, "$s" for the sockname,
"$u" for the sockurl, ...).

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497