...

by ssf=128 self write

I don't think this works. Probably should be just

It works just fine with the ssf=128 in there if I drop the val.<type> statement.

by self write

Regardless, I dropped it and still ended up with the same insufficient access error.

Thanks,

Mark

On 10/16/2013 08:38 PM, Mark Dieterich wrote:

...

You should probably check with slapacl(8).

Thanks Dieter, this might prove to be helpful. Investigating with slapacl, I see some interesting behavior. Without the "val.exact=/bin/bash" requirement, the user is allowed write access and the relevant portions of the ACL trace looks like:

525edc6e => acl_mask: access to entry "uid=testmkd,ou=people,dc=cs,dc=brown,dc=edu", attr "loginShell" requested 525edc6e => acl_mask: to all values by "uid=testmkd,ou=people,dc=cs,dc=brown,dc=edu", (=0) 525edc6e <= check a_dn_pat: uid=.*/admin,cn=cs.brown.edu,cn=GSSAPI,cn=auth 525edc6e => acl_string_expand: pattern: uid=.*/admin,cn=cs.brown.edu,cn=GSSAPI,cn=auth 525edc6e => acl_string_expand: expanded: uid=.*/admin,cn=cs.brown.edu,cn=GSSAPI,cn=auth 525edc6e <= check a_dn_pat: cn=replica,dc=cs,dc=brown,dc=edu 525edc6e <= check a_dn_pat: self 525edc6e <= check a_authz.sai_ssf: ACL 128 > OP 128 525edc6e <= acl_mask: [3] applying write(=wrscxd) (stop) 525edc6e <= acl_mask: [3] mask: write(=wrscxd) 525edc6e => slap_access_allowed: write access granted by write(=wrscxd) 525edc6e => access_allowed: write access granted by write(=wrscxd) write access to loginShell: ALLOWED

and with the "val.exact=/bin/bash" requirement, it looks like:

525ed68a => acl_mask: access to entry "uid=user,ou=people,dc=cs,dc=brown,dc=edu", attr "loginShell" requested 525ed68a => acl_mask: to all values by "uid=user,ou=people,dc=cs,dc=brown,dc=edu", (=0) 525ed68a <= check a_dn_pat: uid=.*/admin,cn=cs.brown.edu,cn=GSSAPI,cn=auth 525ed68a => acl_string_expand: pattern: uid=.*/admin,cn=cs.brown.edu,cn=GSSAPI,cn=auth 525ed68a => acl_string_expand: expanded: uid=.*/admin,cn=cs.brown.edu,cn=GSSAPI,cn=auth 525ed68a <= check a_dn_pat: cn=replica,dc=cs,dc=brown,dc=edu 525ed68a <= check a_dn_pat: uid=.*,ou=people,dc=cs,dc=brown,dc=edu,cn=gssapi,cn=auth 525ed68a <= check a_dn_pat: * 525ed68a <= acl_mask: [4] applying read(=rscxd) (stop) 525ed68a <= acl_mask: [4] mask: read(=rscxd) 525ed68a => slap_access_allowed: write access denied by read(=rscxd) 525ed68a => access_allowed: no more rules write access to loginShell: DENIED

Note the difference in the line following "cn=replica,dc=cs..." Again, the entire ACL stanza in question is:

access to dn.subtree="ou=people,dc=cs,dc=brown,dc=edu" attrs=loginShell val.exact="/bin/bash" by ssf=128 dn.regex="uid=.*/admin,cn=cs.brown.edu,cn=GSSAPI,cn=auth" write by ssf=128 dn="cn=replica,dc=cs,dc=brown,dc=edu" write by ssf=128 self write by * read

I'm at a loss as to why adding the "val.exact=/bin/bash" requirement changes the acl trace from doing:

525edc6e <= check a_dn_pat: cn=replica,dc=cs,dc=brown,dc=edu 525edc6e <= check a_dn_pat: self

to

525ed68a <= check a_dn_pat: cn=replica,dc=cs,dc=brown,dc=edu 525ed68a <= check a_dn_pat: uid=.*,ou=people,dc=cs,dc=brown,dc=edu,cn=gssapi,cn=auth

with the val.exact statement, it doesn't even seem to evaluate the "self" permissions. Am I missing something fundamental here?

When modifying a value with a "replace" modify, first access is checked without values, to make sure one has the right to delete whatever value is present. With the ACL you configured there is no such privilege. You need to split your operation in two: first delete the specific value you want to delete, then add a new value. Both need to comply with the pattern specified in your ACL. For example, if you configure

access to attrs=homeDirectory val.regex="^/bin/[^f][^s][^h]" by self write

then you need to perform

dn: uid=user,ou=people,dc=cs,dc=brown,dc=edu changetype: modify delete: homeDirectory homeDirectory: /bin/bash - add: homeDirectory homeDirectory: /bin/csh

p.

On 10/18/2013 02:53 PM, Mark Dieterich wrote:

...

...

I'm at a loss as to why adding the "val.exact=/bin/bash" requirement changes the acl trace from doing:

525edc6e <= check a_dn_pat: cn=replica,dc=cs,dc=brown,dc=edu 525edc6e <= check a_dn_pat: self

to

525ed68a <= check a_dn_pat: cn=replica,dc=cs,dc=brown,dc=edu 525ed68a <= check a_dn_pat: uid=.*,ou=people,dc=cs,dc=brown,dc=edu,cn=gssapi,cn=auth

with the val.exact statement, it doesn't even seem to evaluate the "self" permissions. Am I missing something fundamental here?

When modifying a value with a "replace" modify, first access is checked without values, to make sure one has the right to delete whatever value is present. With the ACL you configured there is no such privilege. You need to split your operation in two: first delete the specific value you want to delete, then add a new value. Both need to comply with the pattern specified in your ACL.

If I read this correctly, what you are saying is any val.<type>=<test> is completely ignored during the first check of a "replace" modify? This seams like slapd is changing the semantics of my intended ACL. If I truly don't want a user to be able to modify/delete a record unless it matches a given set of values, then what's stopping them from working around any ACL restriction I put in place with the explicit delete & add procedure you outlined? As an aside, I went ahead and tested the explicit delete and add procedure, it failed as well.

I was using slapacl for my tests and I'm not sure how it knows whether the intended procedure is a delete, add, or modify. All I was telling it to test for was whether it could write a particular attribute.

Just for the records, I set

access to attrs=description val.regex="^/bin/[^f][^s][^h]" by users write by * read

access to * by * read

(I didn't feel like populating the database with homeDirectory and so), and it worked: users were able to add/delete "/bin/bash", but not "/bin/fsh".

Glad you found a workaround, though.

p.

Thanks,

Mark

Mark Dieterich wrote:

I need for users who have an existing value of "/bin/fsh" to be prevented from deleting or modifying their entry.

Why don't you use filter=(shell=/bin/fsh) then? Maybe I did not get you right.

Ciao, Michael.

I never figured out how to get any of the val.<type>=<value> restrictions to meet my needs, so I resorted to using sets to accomplish what I wanted. In case anyone else is every trying to do something similar, here is what I ended up with for an ACL statement:

access to dn.regex="uid=.*,ou=people,dc=cs,dc=brown,dc=edu" attrs=loginShell by ssf=128 set="(this & user)/loginShell & ([/bin/csh] | [/bin/sh] | ...) write

By doing this, I ensure the user is editing their own entry and that the current value of the loginShell variable is amongst the list of shells I permit people to change away from. I also have an explicit constraint on loginShell:

constraint_attribute loginShell regex ^(/bin/csh|/bin/sh|...)

earlier in the configuration, which limits what users can set their shell to.

Hope this saves some people from the week or so of ACL fun I've been enjoying ;)

Thanks to everyone who posted suggestions!

Mark

...

[...] val.regex="/bin/[^f][^s][^h]"

It will match "/bin/bash" (that's ok), it will NOT match "/bin/fsh" (also ok), but it will also NOT match "/bin/ash" or "/bin/foo".

Good point. Fortunately for us, I think this pattern works for all shells currently used in our environment. I tried a negative lookahead, which is what I really want, but slapd complained about the syntax.

Mark