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.

One approach that might help here would be to follow something like the MoinMoin approach - a "farm" of RB instances, wherein I only have to configure Apache once, but I still get multiple instances of RB, all independent of each other. I don't understand Django enough to see if this kind of approach is easy/possible with their framework.

*Principle*: Highly restricted access to the operating server.

Only three people have access to remotely log into the server. Since the server stores credentials that access other systems, access to the system must be severely limited. Anything that even might potentially compromise the underlying system must not be exposed to others.

/How does RB currently do?/ Unfortunately, it fails - although your tips below helped me fix it so that it works the way I need, with a minimal amount of code patching. So improvement here looks like it might be easy.

The general guideline here is that *anything* that directly affects the underlying file system, exposes credentials, risks network integrity, or risks normal operation of the server is a problem if it is exposed to anyone other than a superuser.

Dashboard tab:

I can restrict Staff access to just review groups and default reviewers: OK.

Database tab:

I can already restrict staff to specific models: OK

Settings tab:
For some reason, the "siteconfig" permission, which restricts access to this information under the database tab, has no effect on whether you can see the settings if you're "Staff". Specifically, under settings:

General - bad - to non-superuser users - exposes information, which if changed can break the operation of the server, exposes a file system path

Authentication - bad - exposes to non-superuser users the credentials needed to connect to other systems. Also, edits here can break the operation of the server.

Email - bad - exposes credentials

Diff viewer - OK - but oddly these settings feel like they should be per-user.

Logging - bad - exposes a file system path

File Storage - bad - if changed poorly, can affect the operation of the server.

Anyway, since we've got a small number of people who have direct access, and they all have other responsibilities...

*Principle*: Delegated administration.

With a large number of repositories, the small number of people who have access cannot possibly manage the details of "review" configuration. Setting up of groups & default reviewers must be something we can delegate to a large number of people who closer to the specific projects, without risking compromise to the server as a whole.

/How does ReviewBoard currently do?/ OK. Using the "staff" capability, currently available permissions, and a separate instance per underlying code repository as described above, this gets me exactly where I want to be. To be fair, if you don't count the issues from above around restricting key things to just superuser, then ReviewBoard actually does quite well here.

One minor complaint. The distinction between "groups" and "review groups" is initially quite confusing. Minimally changing the label to "authorization groups" would help.

Also, it appears that if you don't set any permissions, you get them all. Seems backwards. Maybe I'm mistaken on this point, but that's what I recall from my poking around.

In any case, after dealing with the issues under restricted access above, it looks like I can configure the server just exactly as I need it.

*Principle*: Keep authorization simple.

Adding lots of different authorization groups just means more testing to make sure that we got the configuration right, and more opportunities for mistakenly exposing data that we shouldn't have. For our ReviewBoard configuration, I think we'll end up having only three classes of user per underlying repository:

   * Superuser
   * Staff
   * Regular user

For the underlying subversion repository, we have four classes of user - the equivalent of "superuser", the equivalent of staff, but two different kinds of "regular user" - one with read-only access, and one with read-write access. We might end up having two different kinds of "regular" user for now, but at the moment, I do not expect that.

/How does ReviewBoard currently do?/ Well, I think. I don't currently feel compelled to create lots of groups to accomplish/restrict various tasks.

Insofar as RB currently has a lot of separate permissions fields, those are probably useful only to the extent that I provide the right capabilities to the staff & to the regular users.

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.

Well, hopefully the above input is useful. I'd be glad to answer any follow-up questions.



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
<ericjohn...@alumni.brown.edu>  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.


Want to help the Review Board project? Donate today at 
Happy user? Let us know at http://www.reviewboard.org/users/
To unsubscribe from this group, send email to 
For more options, visit this group at 

Want to help the Review Board project? Donate today at 
Happy user? Let us know at http://www.reviewboard.org/users/
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to