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

[Roland Mas]

Justin Richer (2003-07-30 10:50:03 -0400) :

> Here's the second proposal for the structure of our RBAC system,
> based on comments made by various people.

A few comments by myself.  Otherwise, I'm all for it (especially if
you can provide a backward-compatible implementation -- at least from
the user's point of view, I don't mind changing the code).

> Role-Based Access Control Proposal for GForge [Draft 2]
>  Justin Richer <jricher @ mitre . org>
>  July 2003

[...]

> 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".

[...]

> Note that an individual tool may define a higher level of
> granularity using the numbers in between these four levels, since
> each higher level automatically subsumes all permissions of all
> lower levels. That is to say, one with Admin privileges can also
> Write and Read, etc.

  See above.  You can't reproduce current behaviour with such a model.

> A Role is effectively a collection of permissions, which can be
> represented as a list of numbers designating the correct permissions
> level:
>
>
> Role: Foo->Bar
>          
>         .---------------.
> Tracker | 3 - Read      |
> --------+---------------+
> Forums  | 6 - Write     |
> --------+---------------+
> CVS     | 0 - None      |
> --------+---------------+
>  ...    | ...           | 
>
> etc.

  Provided the "numbers" get changed to something non-linear (a
collection of bits would be more appropriate in my sense), I agree
with that.

> When a user gets added to a project, the administrator must select
> the Role to place them into, which then determines what permissions
> they have around the site.

[...]

> 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.

> 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.

> Files
> -----

  Interesting too.  I hadn't thought of that.

> [Anything that we missed? People? Snippets? These may need their own
> special sections available only to site-admins]

  I can't comment on that yet (work is rahter busy these days, and
I'll be away for the next two weeks), but I'll think about all that.
In the meantime, please consider my suggestions, and you'll have a
full advocate :-)

Roland.
-- 
Roland Mas

It would be hard to be deader without special training.
  -- in Theatre of Cruelty (Terry Pratchett)