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.