Bill Shannon wrote:
> Ashish Sahni wrote:
>>> Is it possible to limit the codebase that needs these permissions to
>>> some jruby code that gets used by the application, or must the whole
>>> application have these permissions?
>> It is possible to limit the permissions to a set of jruby libs.
>> However, as of now there is a mode wherein the jruby libs would be a
>> part of
>> the WAR (as opposed to being present at a static location)
>
> "A mode", meaning there are other modes as well? What are they?
Correct. There are 2 modes for a Ruby on Rails app to deployed as a web
application
1. Standalone - wherein the jruby and other libs/files are part of the
war file
2. Shared - wherein jruby and other not included as part of the web archive
>
> Seems like we ought to have a way that these security permissions
> could be included in the JRuby package (e.g., in the war file) and
> GlassFish would automatically configure these permissions for the
> war file at deployment time.
That sounds like good feature to have but should no different for
any other libraries (spring, hibernate etc) that require extra privileges
when the security manager is enabled.
>
> Similarly, if I can deploy the JRuby engine separately, and then
> later deploy applications that make use of it, it would be nice if
> there were a way to specify the security permission requirements in
> that mode as well.
I didn't have to explain the modes, did I ;)
>
> And I'm sure things besides JRuby could take advantage of this.
Exactly.
>
> Just trying to make it all more "plug and play"...
Well,. I think it shouldn't be hard to come up with the protocol -
essentially
during deployment the security privs are picked up (from a standard format
in the archive) and added to containers runtime security policy.
I think the key question would be security - does the deployer (role)
always have the
admin privileges ie, prviileges to add permissions to the container's
runtime security policy ?
-Ashish
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>