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?
>
> 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.
Our appserver and ultimately the ee platform should standardize a way to
grant perms to apps at deployment. IMO, it would be best if the
deployment archive containing the grants could be signed, so that the
deployment system could identify the source of the application; which
could be presented for acceptance to the deployer. The acceptance
mechanism could support a don't ask me again for any app from this source.
Since we are on the topic of modes, it would also be good to consider a
classloading mode where our application class loaders interpret code
signatures and capture signer identity in the protection domains of the
classes they load.
>
> 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.
>
If the permission requiring code blocks within the jruby code are
encapsulated in doPriv blocks, stable targeted grants in server.policy
would likely be sufficient for the "shared" mode.
Ron
> And I'm sure things besides JRuby could take advantage of this.
>
> Just trying to make it all more "plug and play"...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>