2:38 a.m.
At slapd.access we read (about the control keywords):
One useful application is to easily grant write privileges to an
updatedn that is different from the rootdn. In this case, since the
updatedn needs write access to (almost) all data, one can use
access to *
by dn.exact="cn=The Update DN,dc=example,dc=com" write
by * break
as the first access rule. As a consequence, unless the operation is
performed with the updatedn identity, control is passed straight to
the subsequent rules.
I have the following question. If below the above ACL we add another ACL
like:
access to dn.subtree="ou=people,dc=example,dc=com"
by dn.exact="cn=Some Other DN,dc=example,dc=com"
by * none
...doesn't this mean that the second ACL will override the first, so
that "The Update DN" will no longer have access to the whole DIT (as was
intended), since, based on the second ACL, "The Update DN"does not have
access to "ou=people" branch? If this is the case, then the first ACL is
not enough, but care must be taken to avoid any privilege revocation(s)
from "The Update DN", by following ACLs.
Or the existence of the former rule means that access has been
*definitively decided* for "The Update DN" (i.e. "by" clause match(es)
in the first ACL) and any subsequent access statements (later ACLs) can
affect *ONLY* other users (i.e. whatever "by" clause matches, *except*
"The Update DN")?? This is what I understand from the statement "As a
consequence, unless the operation is performed with the updatedn
identity, control is passed straight to the subsequent rules."
Can you please clarify which is the case?
Thanks,
Nick
4:37 a.m.
On Fri, May 25, 2012 at 12:38:09PM +0300, Nick Milas wrote:
One useful application is to easily grant write privileges to an
updatedn that is different from the rootdn. In this case, since the
updatedn needs write access to (almost) all data, one can use
access to *
by dn.exact="cn=The Update DN,dc=example,dc=com" write
by * break
as the first access rule. As a consequence, unless the operation is
performed with the updatedn identity, control is passed straight to
the subsequent rules.
I have the following question. If below the above ACL we add another
ACL like:
access to dn.subtree="ou=people,dc=example,dc=com"
by dn.exact="cn=Some Other DN,dc=example,dc=com"
by * none
...doesn't this mean that the second ACL will override the first, so
that "The Update DN" will no longer have access to the whole DIT (as
No. From slapd.access(5):
Access control checking stops at the first match of the
<what> and <who> clause, unless otherwise dictated by the
<control> clause.
In the example above, the first access statement does not have a
<control> clause for dn.exact="cn=The Update DN,dc=example,dc=com" so
it uses the default, which is 'stop'.
Note that your second access statement does not specify any particular
access for dn.exact="cn=Some Other DN,dc=example,dc=com" so it won't
be much use.
Andrew
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------
5:11 a.m.
On 25/5/2012 2:37 μμ, Andrew Findlay wrote:
In the example above, the first access statement does not have a
<control> clause for dn.exact="cn=The Update DN,dc=example,dc=com" so
it uses the default, which is 'stop'.
Fine. Thank you Andrew, I see. Control clauses are on a per-<who>-clause
basis.
Note that your second access statement does not specify any
particular
access for dn.exact="cn=Some Other DN,dc=example,dc=com" so it won't
be much use.
OK, it was just an example. I now see it was incomplete; sorry for the
confusion. At least I made my thinking clear enough.
It should have been:
access to dn.subtree="ou=people,dc=example,dc=com"
by dn.exact="cn=Some Other DN,dc=example,dc=com" write
by * none
Thanks,
Nick
5:56 a.m.
On 25/5/2012 2:37 μμ, Andrew Findlay wrote:
No. From slapd.access(5):
Access control checking stops at the first match of the
<what> and<who> clause, unless otherwise dictated by the
<control> clause.
In the example above, the first access statement does not have a
<control> clause for dn.exact="cn=The Update DN,dc=example,dc=com" so
it uses the default, which is 'stop'.
By the way, let me also ask:
Why when assigning access rights to "entry" and/or "children"
attributes, in most cases - as I have seen from experience - we have to
end with a "by * break" clause?
access to dn.subtree="ou=people,dc=example,dc=com" attrs=children,entry
by dn.exact="uid=admin,ou=people,dc=example,dc=com" write
by * break
The assignment of privileges to children and/or entry attributes on some branch, could
cause problems if we terminate (and implicitly don't allow the evaluation of other
access statements on this what/attrs combination)?
I tend to think that this is needed in case(s) where we want to be able to assign
different privileges (for children/entry attributes) in subordinate branches, using ACLs
following later. But if we follow the rule: "special access rules first, generic
access rules last", i.e. if we place our ACLs for entry/children of the bottom
branches first in the ACL sequence, then a "by * break" clause would not be
required. Is my thinking right?
And a second question:
Are there any cases where access to "children" and "entry" attributes
is determined implicitly, or in all cases (except, I guess, when we specify "access
to *") we should declare access rights to these attributes explicitly?
Thanks,
Nick
8:44 a.m.
On Fri, 25 May 2012, Nick Milas wrote:
Why when assigning access rights to "entry" and/or
"children"
attributes, in most cases - as I have seen from experience - we have to
end with a "by * break" clause?
Because that's a popular style of ACL processing logic to use for those
attributes. As you note, this is done in "most cases", i.e., not all, so
obviously there nothing in the software that requires it.
I'm not sure why the ACLs for entry and children that you tend to see use
that style, but if I recall correctly, they weren't part of the original
ACL design but rather were added in OpenLDAP 2.2 (or maybe 2.3?), so this
may be the result of ACL sets being retrofitted during upgrades.
...
I tend to think that this is needed in case(s) where we want to be
able
to assign different privileges (for children/entry attributes) in
subordinate branches, using ACLs following later. But if we follow the
rule: "special access rules first, generic access rules last", i.e. if
we place our ACLs for entry/children of the bottom branches first in the
ACL sequence, then a "by * break" clause would not be required. Is my
thinking right?
Yes, though you should review any rules without an attrs= clause carefully
to check whether they're setting the rights for the children/entry
pseudo-attributes unexpectedly.
And a second question:
Are there any cases where access to "children" and "entry" attributes
is
determined implicitly, or in all cases (except, I guess, when we specify
"access to *") we should declare access rights to these attributes
explicitly?
I'm not sure what you mean by "determined implicitly" here, so I can't
answer that.
Philip
8:59 a.m.
On 25/5/2012 6:44 μμ, Philip Guenther wrote:
Because that's a popular style of ACL processing logic to use for
those
attributes. As you note, this is done in "most cases", i.e., not all, so
obviously there nothing in the software that requires it.
I'm not sure why the ACLs for entry and children that you tend to see use
that style, but if I recall correctly, they weren't part of the original
ACL design but rather were added in OpenLDAP 2.2 (or maybe 2.3?), so this
may be the result of ACL sets being retrofitted during upgrades.
Thank you Philip, I hope someone can provide some more information on
why "that's a popular style of ACL processing logic to use for those
attributes." (i.e. entry and children pseudo-attrs).
I am wondering: if there is (or there was) nothing in the software that
requires (required) it, why such a style has developed?
Yes, though you should review any rules without an attrs= clause
carefully to check whether they're setting the rights for the
children/entry pseudo-attributes unexpectedly.
You mean that if we use a <what> statement without an "attrs=" clause,
then it affects children and entry pseudo-attributes as well? And what
if there is a filter specified too (still without an "attrs=" clause)?
I'm not sure what you mean by "determined implicitly"
here, so I can't
answer that.
What I meant was exactly that (see above): if e.g. we use a <what>
statement without an "attrs=" clause, then it affects children and entry
pseudo-attributes as well?
Thanks,
Nick
2:55 a.m.
On 25/5/2012 6:59 μμ, Nick Milas wrote:
You mean that if we use a <what> statement without an
"attrs=" clause,
then it affects children and entry pseudo-attributes as well? And what
if there is a filter specified too (still without an "attrs=" clause)?
From some research I did (e.g.:
http://www.openldap.org/faq/data/cache/1140.html), I don't see cases of
implicit change (meant as described above) of entry and children
pseudo-attributes.
In case we would like an ACL statement to include all attributes *plus*
the pseudo-attributes, then we should explicitly specify, for example:
access to dn.subtree="ou=people,dc=example,dc=com"
attrs="@extensibleObject,children,entry"
by dn.exact="uid=admin,ou=people,dc=example,dc=com" write
...
If anyone has more details on this, I would appreciate your feecback.
Regards,
Nick
8:33 p.m.
On Sat, 26 May 2012, Nick Milas wrote:
On 25/5/2012 6:59 ??, Nick Milas wrote:
> You mean that if we use a <what> statement without an "attrs="
clause,
> then it affects children and entry pseudo-attributes as well? And what
> if there is a filter specified too (still without an "attrs=" clause)?
From some research I did (e.g.:
http://www.openldap.org/faq/data/cache/1140.html), I don't see cases of
implicit change (meant as described above) of entry and children
pseudo-attributes.
You didn't see the last example on that page?
----
access to dn.onelevel="dc=example,dc=com"
by dnattr=creatorsName write
by * read
----
No attrs clause, and yet for the behavior described there to work it must
be giving access to the 'entry' pseudo-attr.
In case we would like an ACL statement to include all attributes
*plus*
the pseudo-attributes, then we should explicitly specify, for example:
access to dn.subtree="ou=people,dc=example,dc=com"
attrs="@extensibleObject,children,entry"
by dn.exact="uid=admin,ou=people,dc=example,dc=com" write
...
@extensibleObject covers *EVERYTHING*, including the pseudo-attrs entry
and children.
If anyone has more details on this, I would appreciate your feecback.
Let's do something *crazy*: let's *actually try it*!
I added the following two acls to an existing server
-----
# Just needed so I can add dc=testing...
access to dn.exact="" attrs=children
by dn.exact="mailRoutingAddress=foo(a)foo.com,ou=People,dc=foo,dc=com" write
access to dn.sub="dc=testing"
by dn.exact="mailRoutingAddress=foo(a)foo.com,ou=People,dc=foo,dc=com" write
-----
This server had no dc=testing tree at this point. With those ACLs
present, I was then able to bind as the indicated user and create a
dc=testing entry and an entry below it:
$ ldapadd -D mailRoutingAddress=foo(a)foo.com,ou=People,dc=foo,dc=com -w foobar
dn: dc=testing
changetype: add
objectclass: domain
dc: testing
adding new entry "dc=testing"
dn: ou=foo,dc=testing
objectClass: organizationalUnit
ou: foo
adding new entry "ou=foo,dc=testing"
$
So, no attrs clause on the second ACL but I was able to create entries
covered by it.
I then replaced those two ACLs with this single one:
-----
access to dn.sub="dc=testing" attrs="objectclass,ou,entry"
by dn.exact="mailRoutingAddress=foo(a)foo.com,ou=People,dc=foo,dc=com" write
-----
I.e., the ACL no longer gives write access to the 'children'
pseudo-attribute.
Adding an entry then fails:
$ ldapadd -D mailRoutingAddress=foo(a)foo.com,ou=People,dc=foo,dc=com -w foobar
dn: ou=baz,dc=testing
objectClass: organizationalUnit
ou: baz
adding new entry "ou=baz,dc=testing"
ldap_add: Insufficient access (50)
additional info: no write access to parent
$
I then updated that ACL to include children:
-----
access to dn.sub="dc=testing" attrs="objectclass,ou,entry,children"
by dn.exact="mailRoutingAddress=foo(a)foo.com,ou=People,dc=foo,dc=com" write
-----
...and now the same add succeeds:
$ ldapadd -D mailRoutingAddress=foo(a)foo.com,ou=People,dc=foo,dc=com -w
foobar
dn: ou=baz,dc=testing
objectClass: organizationalUnit
ou: baz
adding new entry "ou=baz,dc=testing"
$
Those two tests together show that the server is indeed checking for the
'children' attr, so it's not that it just wasn't looking.
Finally, let's try using attrs="@extensibleObject" (I only mention it
because that's what the *documention* says is the default.)
-----
access to dn.sub="dc=testing" attrs="@extensibleObject"
by dn.exact="mailRoutingAddress=foo(a)foo.com,ou=People,dc=foo,dc=com" write
-----
$ ldapadd -D mailRoutingAddress=foo(a)foo.com,ou=People,dc=foo,dc=com -w
foobar
dn: ou=quux,dc=testing
objectClass: organizationalUnit
ou: quux
adding new entry "ou=quux,dc=testing"
$
So @extensibleObject clearly must cover 'children'.
I suggest you set up a similar test environment and play around with some
ACLs on a real system. Less theory and more practice will lead to faster
results. For example, you could set up an ACL with a filter clause and
answer your own question about whether that affects the attrs matched.
Philip
12:25 p.m.
On 27/5/2012 6:33 πμ, Philip Guenther wrote:
@extensibleObject covers*EVERYTHING*, including the pseudo-attrs
entry
and children.
Then, the first example at:
http://www.openldap.org/faq/data/cache/1140.html is a bit deceptive, or
it just aims in emphasizing the entry pseudo-attr, by specifying it
explicitly (along with @extensibleObject), when there was no need to.
You didn't see the last example on that page?
...
No attrs clause, and yet for the behavior described there to work it must
be giving access to the 'entry' pseudo-attr.
True, but one could think that the example here empasizes (because this
is what it discusses) the assignment of write privileges and is
incomplete with regard to the assignment of read privileges.
Let's do something*crazy*: let's*actually try it*!
Ha, ha! Thanks Philip. You were great! I was just too lazy! (Too busy as
well, or hoping someone would know and clarify things so we would avoid
testing thoroughly.)
So there is a risk of "implicit" inadvertent changes!
To summarize your findings:
attrs="@extensibleObject"
EQ
attrs="@extensibleObject,entry,children"
EQ
NO attrs= clause
I suggest you set up a similar test environment and play around with
some
ACLs on a real system. Less theory and more practice will lead to faster
results. For example, you could set up an ACL with a filter clause and
answer your own question about whether that affects the attrs matched.
OK, I'll do it.
Nick
6:56 a.m.
On 27/5/2012 10:25 μμ, Nick Milas wrote:
> For example, you could set up an ACL with a filter clause and
> answer your own question about whether that affects the attrs matched.
OK, I'll do it.
I owe an answer on this; I have done the required research and found
that if we use an ACL of the form:
access to <dn>.<scope> filter=<some filter>
(i.e. without "attrs=" clause), then it DOES include entry, children
pseudo-attributes, for all matching entries (according to filter).
For example, we could use a statement like (devised to illustrate the
case):
acces to dn.subtree="ou=TestBranch,dc=example,dc=com"
filter="(|(objectClass=organizationalUnit)(someattr=*))"
by dn.exact="uid=usr,ou=people,dc=example,dc=com" read
by group.exact="cn=Admins,ou=Groups,dc=example,dc=com" write
by * none
to assign privileges to all attrs (including entry, children) of the
parent entry (which has objectClass=organizationalUnit) and of all
entries having a "someattr" attribute.
A useful tool to display access rights is slapacl. For example, we could
use:
slapacl -b "ou=TestBranch,dc=example,dc=com" -D
"uid=usr,ou=people,dc=example,dc=com"
to view in detail the access rights to each and every attribute of that
particular entry by that particular user DN.
Nick
4018
days inactive
4028
days old
openldap-technical@openldap.org
9 comments
3 participants
participants (3)
-
Andrew Findlay -
Nick Milas -
Philip Guenther