bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: [BEP-0003] [RFC] Permissions in product scope
Date Tue, 22 Jan 2013 15:49:39 GMT
On 1/22/13, Andrej Golcov <> wrote:
>> 7. At present components check for TRAC_ADMIN permission explicitly .
>> Some checks might be true for product admins but others do not.
> How does Trac should know when it is the case? That can be quite
> complex and and potentially brings inconsistent behavior.

Yes . That's exactly the dilemma , and that's why I ask .

> I have in mind a little different solution that also has some
> drawbacks but provides consistent behavior:
>  - Site Admin has TRAC_ADMIN permission for parent environment.


>  - Product Admin has  TRAC_ADMIN permission for specific product
> environment.

Do you see anything in particular against introducing PRODUCT_ADMIN permission ?

It seems to me that the boundaries between product and site admins
have to be very clear , and especially not ambiguous in permission
assertions . There are two relevant cases .

  1. Assert TRAC_ADMIN permissions explicitly
      e.g. perm.require(TRAC_ADMIN) . IMO this should always fail in
      product scope unless target user is a TRAC_ADMIN in global
      scope . That's for the sake of warranting environment security and
      stability considering that such explicit assertions in code most of the
      time mean that subsequent code will deal with sensitive data .
  2. Regular assertions in product scope e.g.
      perm.require(TICKET_MODIFY) should always be true for product
      admins, for obvious reasons .

IMO these subtle differences are better handled by including this new
PRODUCT_ADMIN permission rather than assuming by default that users
granted with TRAC_ADMIN in product scope may do this and that . There
is some ambiguity involved .

However I'd like to know further opinions .

>  - Check TRAC_ADMIN permission in product environment should return
> True for Site Admin. IOW, Site admin is also admin for all products.


>  - Site Admin UI has it's own url and is executed in parent
> environment e.g. http://bla/main/admin

+1 , this has always been the case btw .

> - The functionality of the UI
> can be quite different from Product Admin UI, e.g. User management
> must be part of this UI.


>  - Product Admin UI has it's own url and is executed in product
> environment  e.g. http://bla/main/productX/admin

+1 , this has always been the case btw .

> - Product admin can
> assign product specific permissions to user but cannot CRUD users,
> change system specific settings.

This is the complicated part . What are «system» settings for Trac ?
Well, afaics at this moment all settings are just at the same level
i.e. there's no distinction between sensitive information (e.g. DB
connection string) and plain old settings (e.g. target e-mail address
for notifications). IMO product admins should have access to admin
commands beyond permissions management web forms . These are some
examples :

  - Product admins should have access to plugins admin web panel
    (or alike) in order to enable / disable plugins for a particular product .
    Main differences will be the following:
    * Disable web UI controls for components disabled in global
      environment as they cannot be enabled in product scope either
      [1]_ . They should still be visible so that product admin will
      be able to watch available «features» and contact Trac admin
      in order to enable the one(s) that might be needed in product
    * Plugin egg upload form not displayed in product scope.
  - Allow for editing «safe» options to configure plugin / components
    behaviors in product scope . This includes (... but not limited to ...)
    notifications , Google Analytics tracking code , default values for
    ticket fields , ExtensionOption(s) in general ... but IMO not

>  - Product environment should protect from changing of system settings
> and multi-product instances such as Users.


> For example, Product Admin
> (with TRAC_ADMIN permission on specific product) cannot change DB
> connection string. That can be tricky :)


> I don't yet feel myself
> confident enough to say how this can be implemented.

/me neither , that's the ultimate goal of this discussion .

> May be kind of
> black list of system settings?

That's something I've been considering but afaict there are many holes
and , what is worst , I've not found a generic mechanism to get this
done . So like you said that «can be quite complex and and potentially
brings inconsistent behavior».



Blog ES:
Blog EN:

Featured article:

View raw message