Hi all,
Although I suspect what the answer would be, I thought It might be a good idea to confirm with the list.
Is the following <attrlist> clause in OpenLdap's ACLs syntax valid;
<attr1> [val[.<basic-style>]=<regex>],<attr2>
e.g. to dn.subtree="ou=People,dc=foo,dc=com" attrs=entry,objectClass val.regex="objvalue1|objvalue2",attr1,attr2 by <who> <what>
Thanks
On 10/14/2014 09:03 AM, Nikos Voutsinas wrote:
Hi all,
Although I suspect what the answer would be, I thought It might be a good idea to confirm with the list.
Is the following <attrlist> clause in OpenLdap's ACLs syntax valid;
<attr1> [val[.<basic-style>]=<regex>],<attr2>
e.g. to dn.subtree="ou=People,dc=foo,dc=com" attrs=entry,objectClass val.regex="objvalue1|objvalue2",attr1,attr2 by <who> <what>
No. When "val=..." is used, only one attr must appear in the list.
p.
On 10/14/2014 09:35 AM, Pierangelo Masarati wrote:
On 10/14/2014 09:03 AM, Nikos Voutsinas wrote:
Hi all,
Although I suspect what the answer would be, I thought It might be a good idea to confirm with the list.
Is the following <attrlist> clause in OpenLdap's ACLs syntax valid;
<attr1> [val[.<basic-style>]=<regex>],<attr2>
e.g. to dn.subtree="ou=People,dc=foo,dc=com" attrs=entry,objectClass val.regex="objvalue1|objvalue2",attr1,attr2 by <who> <what>
No. When "val=..." is used, only one attr must appear in the list.
Sorry, I involuntarily hit "send" too soon. You can find this bit of info in slapd.access(5):
Using the form attrs=<attr> val[/matchingRule][.<attrstyle>]=<attrval> specifies access to a particular value of a single attribute. In this case, only a single attribute type may be given.
p.
p.
On Tue, 14 Oct 2014, Pierangelo Masarati wrote:
attrs=entry,objectClass val.regex="objvalue1|objvalue2",attr1,attr2
Sorry, I involuntarily hit "send" too soon. You can find this bit of info in slapd.access(5):
Using the form attrs=<attr> val[/matchingRule][.<attrstyle>]=<attrval> specifies access to a particular value of a single attribute. In this case, only a single attribute type may be given.
I do feel it's worth pointing out that, while you're reading that man page, the <control> field may prove particularly useful to apply multiple clauses to your (presumably single) <what> scope.
Besides the obvious workaround, i.e. split the rule into two ACLs, one with the val.regex and another without, I am not sure that I understand how the other special controls (break, continue) can help with this case. Am I missing sth?
On Tue, Oct 14, 2014 at 6:19 PM, Aaron Richton richton@nbcs.rutgers.edu wrote:
On Tue, 14 Oct 2014, Pierangelo Masarati wrote:
attrs=entry,objectClass val.regex="objvalue1|objvalue2",attr1,attr2
Sorry, I involuntarily hit "send" too soon. You can find this bit of info in slapd.access(5):
Using the form attrs=<attr> val[/matchingRule][.<attrstyle>]=<attrval> specifies access to a particular value of a single attribute. In this case, only a single attribute type may be given.
I do feel it's worth pointing out that, while you're reading that man page, the <control> field may prove particularly useful to apply multiple clauses to your (presumably single) <what> scope.
Nikos Voutsinas wrote:
Besides the obvious workaround, i.e. split the rule into two ACLs, one with the val.regex and another without, I am not sure that I understand how the other special controls (break, continue) can help with this case. Am I missing sth?
Each ACL implicitly ends with "by * none" which would stop ACL processing. So you need to add an explicit "by * break" if you want to pass the control flow to the next ACL.
Ciao, Michael.
This is an example of what would be convenient (but is currently not supported): olcAccess: to dn.subtree="ou=People,dc=foo,dc=com" attrs=entry,objectclass val.regex="account|simpleSecurityObject",uid,userPassword by dn="uid=joe,dc=foo,dc=com" read by * none stop
As far as I understand the equivalent of the previous would be: olcAccess: to dn.subtree="ou=People,dc=foo,dc=com" attrs=objectclass val.regex="account|simpleSecurityObject" by dn="uid=joe,dc=foo,dc=com" read by * none stop olcAccess: to dn.subtree="ou=People,dc=foo,dc=com" attrs=entry,uid,userPassword by dn="uid=joe,dc=foo,dc=com" read by * none stop
Now, the "break" control, would let subsequent ACLs evaluate access on the same <what> clause, and if "break" was required for that reason in the 1st ACL it would be needed also in the 2nd and 3rd ACL, but this is irrelevant with the fact that we should split the original <what> clause, since the <what> clauses on 2nd and 3rd ACLs are different. Isn't that so?
On Tue, Oct 14, 2014 at 9:12 PM, Michael Ströder michael@stroeder.com wrote:
Nikos Voutsinas wrote:
Besides the obvious workaround, i.e. split the rule into two ACLs, one
with
the val.regex and another without, I am not sure that I understand how
the
other special controls (break, continue) can help with this case. Am I missing sth?
Each ACL implicitly ends with "by * none" which would stop ACL processing. So you need to add an explicit "by * break" if you want to pass the control flow to the next ACL.
Ciao, Michael.
Nikos Voutsinas wrote:
This is an example of what would be convenient (but is currently not supported): olcAccess: to dn.subtree="ou=People,dc=foo,dc=com" attrs=entry,objectclass val.regex="account|simpleSecurityObject",uid,userPassword by dn="uid=joe,dc=foo,dc=com" read by * none stop
As far as I understand the equivalent of the previous would be: olcAccess: to dn.subtree="ou=People,dc=foo,dc=com" attrs=objectclass val.regex="account|simpleSecurityObject" by dn="uid=joe,dc=foo,dc=com" read by * none stop olcAccess: to dn.subtree="ou=People,dc=foo,dc=com" attrs=entry,uid,userPassword by dn="uid=joe,dc=foo,dc=com" read by * none stop
Now, the "break" control, would let subsequent ACLs evaluate access on the same <what> clause, and if "break" was required for that reason in the 1st ACL it would be needed also in the 2nd and 3rd ACL, but this is irrelevant with the fact that we should split the original <what> clause, since the <what> clauses on 2nd and 3rd ACLs are different. Isn't that so?
Frankly I don't understand your thoughts.
Mainly what you want is (line breaks for readability):
access to dn.subtree="ou=People,dc=foo,dc=com" attrs=objectclass val.regex="account|simpleSecurityObject" by dn="uid=joe,dc=foo,dc=com" read by * break
access to dn.subtree="ou=People,dc=foo,dc=com" attrs=entry,uid,userPassword by dn="uid=joe,dc=foo,dc=com" read by * none
Note that ACL processing implicitly stops at every match and that each ACL ends with implicit "by * none" if nothing else is defined with "by * foo" to match all the rest.
Ciao, Michael.
On Wed, Oct 15, 2014 at 11:07 AM, Michael Ströder michael@stroeder.com wrote:
Nikos Voutsinas wrote:
This is an example of what would be convenient (but is currently not supported): olcAccess: to dn.subtree="ou=People,dc=foo,dc=com"
attrs=entry,objectclass
val.regex="account|simpleSecurityObject",uid,userPassword by dn="uid=joe,dc=foo,dc=com" read by * none stop
As far as I understand the equivalent of the previous would be: olcAccess: to dn.subtree="ou=People,dc=foo,dc=com" attrs=objectclass val.regex="account|simpleSecurityObject" by dn="uid=joe,dc=foo,dc=com"
read
by * none stop olcAccess: to dn.subtree="ou=People,dc=foo,dc=com" attrs=entry,uid,userPassword by dn="uid=joe,dc=foo,dc=com" read by * none stop
Now, the "break" control, would let subsequent ACLs evaluate access on
the
same <what> clause, and if "break" was required for that reason in the
1st
ACL it would be needed also in the 2nd and 3rd ACL, but this is
irrelevant
with the fact that we should split the original <what> clause, since the <what> clauses on 2nd and 3rd ACLs are different. Isn't that so?
Frankly I don't understand your thoughts.
Mainly what you want is (line breaks for readability):
access to dn.subtree="ou=People,dc=foo,dc=com" attrs=objectclass val.regex="account|simpleSecurityObject" by dn="uid=joe,dc=foo,dc=com" read by * break
You are assuming that, there are subsequent ACLs that are going to process the same <what> clause or a superset of it, which might be true or not. However for our specific example, slapd will process the subsequent (2nd) ACL no matter which control was used in the 1st ACL because the two ACLs refer to different what clauses. So, yes break control might be useful but it is not required, at least not in our 2 lines example. Should I go back and read again?
access to dn.subtree="ou=People,dc=foo,dc=com" attrs=entry,uid,userPassword by dn="uid=joe,dc=foo,dc=com" read by * none
Note that ACL processing implicitly stops at every match and that each ACL ends with implicit "by * none" if nothing else is defined with "by * foo" to match all the rest.
Ciao, Michael.
Nikos Voutsinas wrote:
On Wed, Oct 15, 2014 at 11:07 AM, Michael Ströder michael@stroeder.com wrote:
Nikos Voutsinas wrote:
This is an example of what would be convenient (but is currently not supported): olcAccess: to dn.subtree="ou=People,dc=foo,dc=com"
attrs=entry,objectclass
val.regex="account|simpleSecurityObject",uid,userPassword by dn="uid=joe,dc=foo,dc=com" read by * none stop
As far as I understand the equivalent of the previous would be: olcAccess: to dn.subtree="ou=People,dc=foo,dc=com" attrs=objectclass val.regex="account|simpleSecurityObject" by dn="uid=joe,dc=foo,dc=com"
read
by * none stop olcAccess: to dn.subtree="ou=People,dc=foo,dc=com" attrs=entry,uid,userPassword by dn="uid=joe,dc=foo,dc=com" read by * none stop
Now, the "break" control, would let subsequent ACLs evaluate access on
the
same <what> clause, and if "break" was required for that reason in the
1st
ACL it would be needed also in the 2nd and 3rd ACL, but this is
irrelevant
with the fact that we should split the original <what> clause, since the <what> clauses on 2nd and 3rd ACLs are different. Isn't that so?
Frankly I don't understand your thoughts.
Mainly what you want is (line breaks for readability):
access to dn.subtree="ou=People,dc=foo,dc=com" attrs=objectclass val.regex="account|simpleSecurityObject" by dn="uid=joe,dc=foo,dc=com" read by * break
You are assuming that, there are subsequent ACLs that are going to process the same <what> clause or a superset of it, which might be true or not.
Indeed this is very usual in my setups.
However for our specific example, slapd will process the subsequent (2nd) ACL no matter which control was used in the 1st ACL because the two ACLs refer to different what clauses. So, yes break control might be useful but it is not required, at least not in our 2 lines example.
Yes, you're right in your case.
Ciao, Michael.
openldap-technical@openldap.org
-
Aaron Richton -
Michael Ströder -
Nikos Voutsinas -
Pierangelo Masarati