[Date Prev][Date Next]
Re: Global ACLs - Impacts access control and SLAPI (ITS#3100)
I don't think it is broke, but intended behavior:
If their are global acls, they apply to all databases
after any db acls. If the db has no acls, global acls
If the target is not within any database, acls of
first database (then global acls) apply.
It's been this way for many years (long before SLAPI).
At 05:33 AM 4/20/2004, email@example.com wrote:
>Full_Name: Pierangelo Masarati
>Submission from: (NULL) (22.214.171.124)
>Submitted by: ando
>Global ACLs - Impacts access control and SLAPI
>If i read it correctly, I notice that the global_acl are never used, because if
>access_allowed is called when o_bd is NULL, the ACLs of the first backend are
>used instead; then, until the end of access_alowed, the o_bd member remains set
>to this value. I don't think this is correct; apparently it is done to invoke
>slapi ACL code, but this inhibits the use of global ACLs in the rest of the
>code. I fixed this to allow the operation only within slapi code, and restore
>the global_acl usage. If any other code needs o_bd to be set to a "fake"
>backend for auth purposes, I'd rather favour the use of a fake BackendDB
>structure with be_acl member set to global_acl. In my global overlay patch
>(ITS#3080), this is addressed by defining a global BackendDB structure that
>holds global stuff, and can be addressed by o_bd while no backend is selected
>I'll commit the fix in a moment; please review because I'm not sure i did it
>correctly, and ACLs are critical.