tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Casper Wandahl Schmidt <kalle.pri...@gmail.com>
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<chris@christopherschultz.net>:
>> 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]
>> http://stackoverflow.com/questions/10909471/tomcat-web-application-manager-is-it-possible-to-limit-what-each-user-role-can/10937606#10937606
>>
> 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.
True
>
> 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 
role).
>
> 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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
Med venlig hilsen/Kind regards
Casper W. Schmidt


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message