Jesse Kempf wrote:
...
RBAC allows you to assign capabilities on an entity to a list of roles.
That is, you can say "role xyz has write access on /some/wiki/page".
Label-based access control puts a tag on a resource, and actions on
labels can be assigned to principals (set label ReallySecretStuff on
ticket:134; let user puffy see ReallySecretStuff).
It's not exactly clear for me how RBAC and LBAC would interact:
Let's take a practical use case: 'Security' related tickets.
They should not be world-viewable, only the developers should have
r/w access on them.
IIUC, access to tickets labeled with 'Security' could be restricted to
users having a 'Developer' role?
It should then be possible for a non-developer user to report security
issues,
and therefore he should be able to create a new ticket and label it with
'Security'.
He should also be able to view the ticket. That implies the possibility
to have
a rule stating that a 'Security' labeled ticket should be viewable by
its ''reporter''.
This is similar to the situation where a non-privileged user should
nevertheless
be given ''extra'' privileges over resources that he created:
* users should be able to update the attachments they uploaded
* users should be able to modify the comments they wrote
* ideally, users should be able to modify the ticket description they
entered
At this point, I should state that a 'resource' in the Trac context is
the same as an 'entity'. An 'entity' is any wiki page, ticket,
milestone, or other information object to which trac gives a user
access.
The "Mandatory Access Control" that I mentioned in my previous email
trips over the trusted-system definition of MAC and gloms some things
together inappropriately. We can divide this into two parts:
Part 1: Non-Circumventable Access Control:
Requirement: It must not be possible for a Component (read: malicious
(or clueless) plugin to circumvent the security system.
Consequence 1: Access control must be implemented as close to the data
access layer as possible.
Ok
Consequence 2: It must not be possible to acquire a reference to the
SecuritySystem component, then redefine its methods, thus bypassing the
system entirely.
Not sure it's worth (see Noah's mail): protecting about 'clueless'
plugins should be enough.
Part 2: Mandatory Access Control:
Requirement: It should not be possible for an owner of an entity to
assign to an entity access controls more permissive than the system
security policy.
Explanation: If a Trac Admin declares that tickets may only be read by
authenticated principals, it should not be possible for the ticket owner
to allow anonymous access to his ticket.
Ok
It's essential to keep in mind that Trac is lightweight, and by all
means intended to remain lightweight. While in the long-term we'll
need some way to allow people to have some wiki pages / tickets only
readable/modifiable/etc by some groups of people, an acceptable
solution needs to be reasonably flexible but simple. Per-entity ACLs
are something that I personally think is overkill, for example.
Doing any sort of access control is non-trivial, and the devil is in the
details. If we want a simple implementation of the access control
system, then we heap a lot of complexity upon the client (say, making
trac.wiki.web_ui do access control...). If we want simplicity for the
client, then the implementation is going to be somewhat complicated.
Let me be clear by saying that I intend to make the security system as
transparent to the programmer as possible (to the point where a naive
Component written for trac 0.9's security model should still function
(with a few minor changes, maybe) while allowing aware components full
access to a powerful security system.
To put it more concisely, unless you want to use the access control
system or touch an entity that's access-controlled, you don't need to
even know it's there. And if you do, it's not going to be much different
than the way things are now.
Let's take a concrete example:
a wiki page contains ticket references, each of which normally
"decorated" with the href title being the summary of the ticket.
Access to such information should be filtered, e.g. if the user
does have a read permission on the wiki page but not one some
of the tickets, those tickets references should not contain the
summary, but rather be displayed as "missing".
Consider the code we have now for that
(source:trunk/trac/ticket/[EMAIL PROTECTED])
cursor = formatter.db.cursor()
cursor.execute("SELECT summary,status FROM ticket WHERE id=%s",
(target,))
At the data access layer, say:
create_dbhandle_for_principal(princ)
get_request(sqlstatement)
if_uses_advanced_access_control(caller)
transform(sqlstatement) #make access aware query
return execute(sqlstatement)
Do you want to ''transform(sqlstatement)'' this into a query which
checks if the needed resource is readable?
This would first require to _infer_ the resource we're about to read
from the SQL query itself...
Eventually possible on the "SELECT summary..." query above,
but what about more complex ones?
I think a programmatic access to the data layer would be
a prerequisite to make this practical.
-- Christian
_______________________________________________
Trac-dev mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac-dev
