Re: [Gforge-devel] RBAC Proposal - Draft 2

[Justin Richer]

My replies to Roland's comments.

> > Permissions are based on ten possible levels for each tool, with
> > four levels set aside for common permission settings. While the
> > meaning of these four levels can vary with each tool (See Appendix:
> > Tool-level permissions), it is easiest to think of the four levels
> > as the following:
> 
>   I dislike the hard-coding of the number of levels, and more
> importantly I'm not quite sure it's going to be linear.  I mean, the
> set of privileges is not necessarily fully ordered.  In the current
> scheme at least, you can be a tracker technician without being an
> admin, or the opposite, which means there's no way to represent these
> privileges by a single comparison between numbers.  I'm talking of the
> admin privilege as in "is able to assign bugs to someone", not the
> "has r00t on the tracker and can change attributes of the tracker
> itself".
> 

I dislike the notion of having things hardcoded as well, but nothing is
really limiting new systems to having only 10 available items, other
than the administrative interface. To make it fully configurable, we'd
have to keep track of min and max values for each category. 

Your comments about the linearity of permissions is interesting though;
I hadn't quite thought of it that way previously. A permission for a
given tool could still be stored as an integer, but that integer would
be the ORed value of all given permissions. We'd run into the same
problem of hard-coding the possible number of bits in a bitfield for
each tool, just like above, but maybe we should just say "32 levels of
granularity should really be enough for any one tool". After all, if a
tool allows someone to do 32 distinct things, maybe it should be broken
up a bit more? :) This also allows us to set the 'Own' options that
R.Spisser was talking about for the Tracker artifacts.

Additionally, the admin interface gets a bit stickier with a bitfield.
It makes most sense to me to allow a grid of checkboxes for the various
levels of access, though labelling becomes a bit problematic as the grid
has potential to get very large. I find the current
Tech/Admin+Tech/Admin dropdown to be a clumsy approach, though,
especially with anything more than the two bits to change.


> > The permissions table would consist of:
> >
> >   perm_id - unique string id for this permissions set ("tracker",
> >             "cvs", "plugin_helloworld")
> >
> >   name - user-readable string name of this permissions set
> >             ("Tracker", "CVS", etc)
> >
> >   default - integer default level of the permission for a newly
> >             created role [also useful for handling plugins that get
> >             added at a later time, though plugins have the option of
> >             filling in roles_perms with their preferred default
> >             information however the plugin chooses]
> >
> > A user's Role within a group could be easily controlled using a new
> > column the user_groups table, role, which would have an integer
> > point to a role_id in the roles table.
> 
>   Again, I fear a loss in generality.  While this would have worked
> for Sourceforge 2.5 (and I'm not sure about that), I believe it can't
> be done simply in Gforge without losing granularity.  We have a
> dynamic set of trackers in Gforge, and they do not necessarily share
> the same permissions, let alone the same people.  Gforge currently
> allows one person to be the "dispatcher" of one particular bug
> tracker, and another one to be the "dispatcher" for another.  Remember
> the support requests tracker, the bug tracker and the patch tracker
> have been merged into a single model, called the artifact tracker.
> (The VA folks also added a "feature requests tracker", but I suspect
> that was merely a move to show off that they could do it :-)  I think
> the same argument is also valid for forums, except I'm not sure people
> can have different permissions on different forums within the same
> group on the current implementation.
> 
>   That could be done if you change the permissions set to be
> per-tracker rather than per-tracker-type-in-a-project.  But then you
> have to create a new permission set for each tracker you create.  On
> that point, it's implementation details from now on, I guess.
> 

I had missed the fact that individual trackers could have different
permissions set on them for users in my initial survey of GForge. That
does change things up a bit, as we now need to account for these
different trackers. Need to think about this some more, but my first
reaction is allow setting of overal Tracker status (can "r00t" the
tracker, as you put it :)) apart from the individual tracker
capabilities, and have them listed under Project->Tracker->Foo or
somesuch. The problem comes when dealing with creating new Trackers and
fitting existing roles to them. 

This brings up another interface issue that I haven't fully thought of.
Ideally, one would like to be able to edit permissions both on a role
level and on a tool level. While this would accomplish the same thing,
it's the administrative effort required, and we don't want to make
things any harder.

We could allow for direct access to editing roles from the individual
tool pages. Perhaps the system could intelligently create/manage user
roles in the background? This can kinda break away some of the benefits
of a role system (like grouping similar users under a single role and
managing permissions that way). All said, I think it's more of an
interface issue than an implementation issue at this point. Any thoughts
on the matter?


> > Permission Sets Per Tool
> > ------------------------
> 
>   I agree with this table (apart from my first argument), but if you
> account for my second argument it should be "Per Tool Category".  By
> "category" here I mean tracker/project manager/lists/forums/etc.
> 
> > [Note: There is a correlation between news items and forums that
> > needs to be worked out with permissions]
> 
>   Sounds reasonable.
> 
> > CVS
> > --- 
> >
> > [Note: this assumes some Chora integration, as Chora could actually
> > pull the session and permission values in from the website more
> > easily than another tool.]
> >
> >   "cvs"
> >   0: None
> >     - No access; can't browse, download, upload, anything.
> >   3: Read
> >     - Can browse the archives online [Chora]
> >     - Can download any file/directory in the archive 
> >       (export / anonymous checkout)
> >     - Can't check out as a user
> >   6: Write
> >     - Can check in / check out files
> >     - Can delete/manage files
> >     - Can create new modules
> >   9: Admin
> >     - Same as 6: Write
> 
>   I'm not sure CVS itself allows such a fine granularity on rights
> management.  Hence, I'm not sure it's interesting to implement it on
> the web if you can get around the checks by using CVS directly.
> 

Well, it does, after a fashion. Effectively, you can get CVS read-only
access using anonymous means and read/write access using account-based
means. This would largely be useful for deciding what to do with
somewhat anonymous people (non-logged-in or logged-in-non-member).



Thanks for your comments, they're much appreciated. We'll look into the
bitfield ideas and see what we can come up with.

 -- Justin