Re: Why is "Settings" available to "Staff"?
Hi Eric, Thanks for the detailed analysis. This is very helpful for our plans. I'll address the issues inline. On Thu, Nov 18, 2010 at 3:43 PM, Eric Johnson wrote: > *Principle*: Use corporate authentication mechanism. > > We don't want people to have to remember a gazillion passwords. > > /How does RB currently do?/ Decently. I couldn't figure out how to get the > "ActiveDirectory" approach to work, so I fell back to standard LDAP, which > eventually worked - once I looked at the code to figure out what the > settings were used for. However, the name of the setting "Anonymous User > Mask" didn't match what I eventually got to work. Our company doesn't allow > for anonymous connections to ActiveDirectory, so we need to have a "Lookup" > user and password, but that's not what these fields are named. > > What would help make this even better? Better field labels. Sample > configurations, diagnostic tips. Even pointers to the code so that people > can just go look to see what it is doing. This is definitely an area that could be improved. I will admit, I personally do not have a lot of LDAP experience. The names chosen were based on the configuration fields provided when we were provided with the initial LDAP module, but we can absolutely change them. I welcome recommendations there to make things clearer, on both label names and any help text. > *Principle*: "Respect" access control permissions on the underlying version > control system. > > We're setting this up against a Subversion server hosting multiple > repositories. Each repository has a different list of users that have > permission to access the repo. Mapping this to reviewboard, we do not want > just anyone to be able to see patches against these repositories - only the > people who already have access to the underlying Subversion server. > > To make this work with Subversion, we're grabbing access information from > the Subversion server, and automatically updating reviewboard projects with > the usernames allowed. > > /How does RB currently do/: So-So. For the moment this amounts to a Custom > Authentication method. What I've currently done is simply hack the existing > LDAP authentication method. For us, this is both a custom authentication & > authorization mechanism, at least insofar as authentication fails for people > who should not have access. One of the tasks currently underway for 1.6 is to allow objects to return whether or not they're accessible by a given user. At the moment, this is based on the per-group and per-repository permissions set for the given user (another new feature in 1.6), but the intent is to allow this to be extended. I had planned to allow them to be extended through our upcoming extension mechanism, but perhaps we can also ask the auth module. ACLs for Subversion are something I would like to support in some fashion, so I'm keeping that in mind. A couple other things on my mind (hopefully for 1.6, maybe 1.7) is the ability to more easily configure authentication modules. Much like SCMTools, I would like third parties to be able to create an auth module and have Review Board auto-discover it. Part of this would be to move the configuration aspects into the module, which would allow Review Board to ask the third-party module for the form data to display during configuration. I imagine this would help a little in your case (or would have if you were writing from scratch). One thing we may want to do is have a new layer, something separate from both extensions and the authentication module, which would be used for specifying whether a user has permissions to some thing (a repository, repository + path, review request, etc.) and go through that. Then, you could keep using the standard LDAP module, and instead provide one of these that could be configured through the admin UI. This would be the thing that checks with Subversion to determine whether they can see a particular file. I'll think about how best to do this. > > Better docs on how to set up a custom authentication mechanism would be > great. This may not be much more than a pointer to the existing > implementations, pointers to the Django docs, and pointers on how to update > ReviewBoard configuration so that new auth mechanisms can be used. I do want to write developer docs on writing custom auth modules and SCMTools. Hopefully for 1.6. There's a lot to juggle. > I've set up an automated process whereby user status (active/inactive) > (staff/not staff) is updated by a cron job directly writing to the auth_user > table in the database. This works. From what I know, I haven't figured out > a better way to accomplish the same thing. If my approach really is the > best way, it would be nice to document, and if it isn't, I'd love to see > docs on the best way. What triggers the change? Is this just asking Subversion and updating the data, in order to keep RB in sync with your Subversion ACL? > With 1.5, as per previous discussion,
Re: Why is "Settings" available to "Staff"?
Hi Christian,
Thanks for your swift response! I was able to block access according to
my needs, so that was very helpful.
I've got more feedback below. This ended up being a long email, in
hopes that it would provide lots of useful information for your aims.
On 11/17/10 7:15 PM, Christian Hammond wrote:
Hi Eric,
Today, there isn't anything for that. You can work around this by
patching reviewboard/admin/views.py to have site_settings check
request.user.is_superuser and return some sort of result (redirecting
to the login page, or something), and patching
templates/admin/base_site.html to add {% if user.is_superuser %} ...
{% endif %} around the link for Settings.
Our main priority with the upcoming Review Board 1.6 release is to add
more fine-grained access to the site. What's in right now is the
ability to restrict access to review groups and repositories (which
then affects review requests). We also need to provide finer-grained
restriction to the admin UI. This will include settings.
Now I haven't quite worked out how best to do this. Depending on how
you're using Review Board, you may want to restrict access to all
settings for everyone but the superuser, but you also may want to
allow it for a select set of non-superusers. The reason for this is
that the 1.6 release will allow partitioning Review Board into a bunch
of separate virtual installs ("local sites"), all running off the same
database and software. This would allow you to, say, provide a Review
Board install for developers and one for QA and one for UE, all
separated with their own groups and such. In such a setup, maybe each
one has its own set of admins that shouldn't be global superusers, and
maybe they should have control over *some* settings but not others.
Since you ask for input below, here's some. Specifically, I'm going to
lay out the organizing principles we're working with, and how we've
implemented (so far) with ReviewBoard. This is for projects that are
*not* open source, so we have all sorts of access concerns
*Principle*: Use corporate authentication mechanism.
We don't want people to have to remember a gazillion passwords.
/How does RB currently do?/ Decently. I couldn't figure out how to get
the "ActiveDirectory" approach to work, so I fell back to standard LDAP,
which eventually worked - once I looked at the code to figure out what
the settings were used for. However, the name of the setting "Anonymous
User Mask" didn't match what I eventually got to work. Our company
doesn't allow for anonymous connections to ActiveDirectory, so we need
to have a "Lookup" user and password, but that's not what these fields
are named.
What would help make this even better? Better field labels. Sample
configurations, diagnostic tips. Even pointers to the code so that
people can just go look to see what it is doing.
That only gets us /authentication/, leaving authorization...
*Principle*: "Respect" access control permissions on the underlying
version control system.
We're setting this up against a Subversion server hosting multiple
repositories. Each repository has a different list of users that have
permission to access the repo. Mapping this to reviewboard, we do not
want just anyone to be able to see patches against these repositories -
only the people who already have access to the underlying Subversion server.
To make this work with Subversion, we're grabbing access information
from the Subversion server, and automatically updating reviewboard
projects with the usernames allowed.
/How does RB currently do/: So-So. For the moment this amounts to a
Custom Authentication method. What I've currently done is simply hack
the existing LDAP authentication method. For us, this is both a custom
authentication & authorization mechanism, at least insofar as
authentication fails for people who should not have access.
Better docs on how to set up a custom authentication mechanism would be
great. This may not be much more than a pointer to the existing
implementations, pointers to the Django docs, and pointers on how to
update ReviewBoard configuration so that new auth mechanisms can be used.
I've set up an automated process whereby user status (active/inactive)
(staff/not staff) is updated by a cron job directly writing to the
auth_user table in the database. This works. From what I know, I
haven't figured out a better way to accomplish the same thing. If my
approach really is the best way, it would be nice to document, and if it
isn't, I'd love to see docs on the best way.
With 1.5, as per previous discussion, I am going to set up a separate
review board instance for each repository, as each repository has a
separate access list. Note that, even with the changes you've talked
about for 1.6, I'm not sure we'd change this approach, as we're
concerned about both leakage and interference. Not even having the same
underlying MySQL database is actually useful.
Re: Why is "Settings" available to "Staff"?
Hi Eric,
Today, there isn't anything for that. You can work around this by
patching reviewboard/admin/views.py to have site_settings check
request.user.is_superuser and return some sort of result (redirecting
to the login page, or something), and patching
templates/admin/base_site.html to add {% if user.is_superuser %} ...
{% endif %} around the link for Settings.
Our main priority with the upcoming Review Board 1.6 release is to add
more fine-grained access to the site. What's in right now is the
ability to restrict access to review groups and repositories (which
then affects review requests). We also need to provide finer-grained
restriction to the admin UI. This will include settings.
Now I haven't quite worked out how best to do this. Depending on how
you're using Review Board, you may want to restrict access to all
settings for everyone but the superuser, but you also may want to
allow it for a select set of non-superusers. The reason for this is
that the 1.6 release will allow partitioning Review Board into a bunch
of separate virtual installs ("local sites"), all running off the same
database and software. This would allow you to, say, provide a Review
Board install for developers and one for QA and one for UE, all
separated with their own groups and such. In such a setup, maybe each
one has its own set of admins that shouldn't be global superusers, and
maybe they should have control over *some* settings but not others.
So, we need to figure that out. And none of that will help you until
1.6 (unless you want to try betas as they come out), but since it
sounds like you're partitioning responsibilities like this already,
getting your input is very helpful.
Christian
--
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com
On Wed, Nov 17, 2010 at 6:43 PM, Eric Johnson
wrote:
> I'm struggling with a particular configuration problem.
>
> I've got three classes of users... Ones that can work on reviews, ones that
> can do anything (superusers), and ones I want to restrict to being able to
> muck around with the admin/database models for changesets, diffs, and reviews.
>
> The "Staff" setting is almost perfect for this in-between role, in that it
> appears that I can set up a group that staff members belong to, and give
> specific permissions to them. Notably, I can prevent them from changing
> authorization config, scmtools, sites, and siteconfig. That fixes everything
> under ./admin/db area, however, the staff members can still see the
> ./admin/settings/... URLs, and even change them.
>
> Is there any way to block the settings (general, authentication, e-mail, ...
> ) from staff users? Or at least prevent them from making changes? I've been
> digging around the code, and haven't figured it out.
>
> I'm okay with making patches to my local copy, if that's what it takes.
>
> Eric
>
>
> --
> Want to help the Review Board project? Donate today at
> http://www.reviewboard.org/donate/
> Happy user? Let us know at http://www.reviewboard.org/users/
> -~--~~~~--~~--~--~---
> To unsubscribe from this group, send email to
> reviewboard+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/reviewboard?hl=en
--
Want to help the Review Board project? Donate today at
http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~--~~~~--~~--~--~---
To unsubscribe from this group, send email to
reviewboard+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/reviewboard?hl=en
Why is "Settings" available to "Staff"?
I'm struggling with a particular configuration problem. I've got three classes of users... Ones that can work on reviews, ones that can do anything (superusers), and ones I want to restrict to being able to muck around with the admin/database models for changesets, diffs, and reviews. The "Staff" setting is almost perfect for this in-between role, in that it appears that I can set up a group that staff members belong to, and give specific permissions to them. Notably, I can prevent them from changing authorization config, scmtools, sites, and siteconfig. That fixes everything under ./admin/db area, however, the staff members can still see the ./admin/settings/... URLs, and even change them. Is there any way to block the settings (general, authentication, e-mail, ... ) from staff users? Or at least prevent them from making changes? I've been digging around the code, and haven't figured it out. I'm okay with making patches to my local copy, if that's what it takes. Eric -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en
