Hi all,
I know it would add lots of new CPU cycles and performance issues,
but:
There are some global group rights that permit something
to some privileged users. It would be interesting for certain queues
to prohibit some of those rights from the global configuration.
Same thing would be interesting for certain users out of a group to override
(and revoke) the group rights.
I expect that it would require changes in ACL table structure, so
this might be a TODO task for RT 3.1 or something.
Cheers,
Stan
Hi all,
I know it would add lots of new CPU cycles and performance issues,
but:
There are some global group rights that permit something
to some privileged users. It would be interesting for certain queues
to prohibit some of those rights from the global configuration.
Same thing would be interesting for certain users out of a group to override
(and revoke) the group rights.
It would definitely be interesting and when I designed the ACL system we
have now, I spent a long time thinking about how we could accomplish
this without crippling the system’s performance. I didn’t have any
bright ideas. Do you?
I expect that it would require changes in ACL table structure, so
this might be a TODO task for RT 3.1 or something.
Cheers,
Stan
rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
Hi Jesse,— Jesse Vincent jesse@bestpractical.com wrote:
On Wed, Jul 30, 2003 at 06:14:59AM -0700, Stanislav Sinyagin wrote:
There are some global group rights that permit something
to some privileged users. It would be interesting for certain queues
to prohibit some of those rights from the global configuration.
Same thing would be interesting for certain users out of a group to override
(and revoke) the group rights.
It would definitely be interesting and when I designed the ACL system we
have now, I spent a long time thinking about how we could accomplish
this without crippling the system’s performance. I didn’t have any
bright ideas. Do you?
As far as I understand, now you follow down the group hierarchy and global->queue level
hierarchy until you find the required privilege.
In this new feature design, we follow the hierarchy down to the end
and collect the information about required privilege.
Thus the lower levels of the hierarchy may have a chance to revoke
the right if it’s given on upper level.
Then we store it in a cache, which should be designed to give three types
of answers:
– Principal A has privilege B for object C
– Principal A does not have privilege B for object C
– There is no information in the cache about this (A,B,C) triple.
When the privileges are edited, the cache should be cleaned in that part that
is concerned. Or, probably it’s easier to clean the whole cache.
seems quite affordable to me…
Stan
In this new feature design, we follow the hierarchy down to the end
and collect the information about required privilege.
Thus the lower levels of the hierarchy may have a chance to revoke
the right if it’s given on upper level.
Perhaps it’s even cheaper to climb the hierarchy from its bottom:
from queue rights to global rights, and from user rights to the groups
it belongs to, and so on. Then the first grant or revocation
that we meet will give us the answer.
There also needs to be a conflict resolution mechanism:
User X belongs to groups G1 and G2. In G1 or its parents, the required privilege
is granted, but in G2 it’s revoked.
Maybe we need two types of revocation:
– Soft revocation: in conflict situation, permission is stronger than denial
– Hard revokation: in conflict situation, denial has absolute power.
yeah, looks like a nightmare for system administratiors…
Stan
Stanislav Sinyagin a écrit :
There also needs to be a conflict resolution mechanism:
User X belongs to groups G1 and G2. In G1 or its parents, the required privilege
is granted, but in G2 it’s revoked.
In this case, we could look at how G1 and G2 privileges are related to
the object. For example, if G1 rights on a ticket were globally assigned
and G2 ones were assigned at queue level, G2 revocation had highest
precedence and thus should be applied… In the reverse case, G1 grant
would have highest precedence.
I think all this really needs to be cached…
Guillaume Perréal.
Responsable informatique,
Cemagref, groupement de Lyon,
France.
Tél: (+33) 4.72.20.87.87.
Fax: (+33) 4.78.47.78.75.
Site: http://www.lyon.cemagref.fr/