tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Casper Wandahl Schmidt <>
Subject Re: [POLL] Finer-grained "manager" user-access privileges?
Date Fri, 08 Jun 2012 11:32:40 GMT
Not much into all of this but here goes...

Den 08-06-2012 13:06, Konstantin Kolinko skrev:
> 2012/6/7 Christopher Schultz<>:
>> I was just answering a question on StackOverflow[1] about limiting the
>> operations a particular user could perform when using the manager app
>> (e.g. deploy, undeploy, start, stop, etc.).
>> It seems to me that this has come up on the users' list once or twice
>> in the past, and it wouldn't be a big deal to support this kind of
>> thing right out of the box by just defining a number of additional
>> roles such as:
>>    manager-gui-deploy
>>    manager-gui-undeploy
>>    manager-gui-start
>>    etc.
>> Is there any interest in doing something like this? My general feeling
>> is that manager access should either be allowed read-only (which is
>> covered by the "manager-status" role) or full read/write (which is
>> covered by the "manager-gui" and "manager-sript" roles) because hey,
>> you should trust your managers or fire them ;)
>> On the other hand, if there is significant interest in this kind of
>> thing, we should support it out of the box.
>> [1]
> I have several ideas where more fine-grained control would be useful.
> But all of them cannot be solved with configuration alone and need
> some checks in Java.
> I do not like to go there.
> Specifically I do not like hard-coding role names into code. I think
> there could be some helper component that could help in access checks.
> (To be discussed separately). It will need some model to map access
> checks to roles.
Eventually you would have to hardcode something right? Unless the 
component is a way of overriding/extending the existing checks for 
manager-gui and manager-script in java (ie. not some config file since 
the checks would need some hardcoded stuff to identify the right roles 
etc. in the config).
> What should we do with "list applications" page? Should it filter
> itself and hide unaccessible actions? I think that is what will be
> asked next.
That would be quite trivial wouldn't it?
> Overall,  more complexity in configuration ->  harder to manage and audit.
> There is such motto as KISS (keep it simple). The current separation
> of roles was introduced to split human-friendly UI (protected from
> CSRF) and other interfaces (which cannot be protected). Essentially it
> is the same as the "allow all" role of "manager" that we had until
> recently.
Well since the manager-gui vs. manager-script split has already been 
done, why not use more fine-grained options (ie. manager-deploy, 
manager-redeploy etc. and then maybe let manager-gui and/or 
manager-script roles decide when those other roles apply (ie. UI og 
script version of the deploy, redeploy etc.)). This would mean that you 
need manager-gui and manager-??? in order to have the rights (maybe let 
manager-all be default if no specific role is applied besides gui/script 
> If there is a way to implement your feature in a simple and
> transparent way, I would not mind it. But I do not see such a way.
> If one has specific requirements, to allow only some specific actions
> to "un-trusted" users, the current way is to implement a custom web
> application.
> Best regards,
> Konstantin Kolinko
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
Med venlig hilsen/Kind regards
Casper W. Schmidt

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message