[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: more access control puzzlement
On 12 May, Eric S. Johansson wrote:
>
> I've encountered a couple more puzzling things with access control. I'm
> trying to control access by IP address and a portion of the hierarchy.
>
> The rules I want are:
> provide limited access (specific attributes, limited part of the
> hierarchy) to a group of machines,
> show everything to one particular host (within a limited part
> of the hierarchy),
> deny everything to everyone else.
>
> then I need to repeat these rules multiple times each one limiting access
> to a different part of the hierarchy. Last, I need a rule granting access
> to a couple of machines for the entire hierarchy.
>
> So reading between the lines, I put in multiple rules and they look like this:
>
> access to dn="*,ou=gems,o=store" attrs=sn,entry
> by addr="206.34.215.253" read
>
> access to dn="*,ou=gems,o=store"
> by domain="localhost" write
>
> defaultaccess none
>
> what seems to happen is that the first rule is used but the second one is
> ignored.
[snip]
If I read this right, then there are probably two problems:
--Your limited access to attributes limits to a single host,
206.34.215.253, not as you wrote above where you wanted to
limit specific attributes to a group of machines. Similarly,
you limit full access to a domain (localhost).
--I doubt that by domain="localhost" would work properly.
localhost is generally mapped to 127.0.0.1, which is the
local network device (sometimes called lo). It isn't supposed
to map to any valid (or illegal, e.g. 192.168.*.*) IP address.
Maybe something like this will work? Assume the host that
gets full access is 192.168.1.1, and the domain that gets
limited access is pizza.com:
access to dn="*,ou=gems,o=store" attrs=sn,entry
by domain="pizza.com" read
access to dn="*,ou=gems,o=store"
by addr="192.168.1.1" write
defaultaccess none
If the group of machines you want read access is more
varied (across domain names, or not all hosts in a domain),
this definitely won't work. (No guarantees anyway, since
I don't have much practice writing ACLs.)
-- Keith
kkeller@slip.net