Quanah Gibson-Mount wrote:
--On Thursday, September 20, 2007 6:37 PM -0700 Russ Allbery rra@stanford.edu wrote:
Howard Chu hyc@symas.com writes:
So, for those of you using sets - why are they useful to you, and in what ways are they still too limited? I personally am concerned that they are too expensive to evaluate; if we could provide similar features using a less general model that would be worth exploring too.
I inherited this setup, so I don't know how useful it is or if there are better ways of expressing the same thing, but we use it for:
access to dn.children="cn=people,dc=stanford,dc=edu" by set.exact="this/uid & user/uid" sasl_ssf=56 read
This allows users who bind to the server to read their person entry when their binding user id matches the user id in the people tree.
I guess that makes sense. What is an example "user" in this case, does that reside under the people tree, or the accounts tree?
access to dn.children="cn=nis,dc=stanford,dc=edu" by set.exact="this/host & user" sasl_ssf=56 read
This was an experimental ACL for doing host based restrictions of user logins. It currently will never be used since this was never deployed. Still a cool idea though, I think. ;)
That would require your "host" attribute to use DN syntax. So presumably the user in this case is an nss_ldap proxy account...?
access to dn.children="cn=accounts,dc=stanford,dc=edu" by set.exact="this/uid & user/uid" sasl_ssf=56 read by * break
This allows users who bind to the server to read their account entry when their binding user id matches the user id in the entry in the account tree.
Don't users just bind using account entries anyway? Isn't this the same as "by self read" ? Or you're saying that there can be multiple accounts with the same uid?
Basically, the first and third acls allow Stanford users to have full read on their own data, but keeps the restrictions in place on all other peoples data in both trees.