Hi
You can have permission to use doPrivilaged without having all of the other
permissions. You can also merge permission domains in the later versions
of the VM which allows the container to add permissions to a thread. Basically,
code in the container can be marked as privilaged which will then allow it
to call restricted methods in spite of the fact that the higher methods in the
stack do not have the privilage to do this. The issue with this is that
calling doPrivilaged has quite a high overhead and container providers
do not wish to do this for every call to code in the container by an EJB.
Resources allow more control over this.
The EJB spec does not specify that EJBs are loaded via their own classloaders -
this is merely the normal method of implementation. In your example, the classloader
does affect the result as well, but not solely.
>From the documentation of doPrivilaged:
>Today all code shipped as part of the SDK is considered system code and run inside the
>unique system domain. System code automatically has all permissions.
>Each applet or application runs in its appropriate domain, determined by its code
>source.
>In order for an applet (or an application running under a security manager) to be
>allowed
>to perform a secured action (such as reading or writing a file), the applet or
>application
>must be granted permission for that particular action.
>More specifically, whenever a resource access is attempted, all code traversed by the
>execution thread up to that point must have permission for that resource access,
>unless
>some code on the thread has been marked as "privileged". That is, suppose access
>control
>checking occurs in a thread of execution that has a chain of multiple
>callers. (Think of this as multiple method calls that potentially cross the protection
>domain boundaries.) When the AccessController checkPermission method is invoked by the
>most recent caller, the basic algorithm for deciding whether to allow or deny the
>requested access is as follows:
> If the code for any caller in the call chain does not have the requested permission,
> AccessControlException is thrown, unless the following is true - a caller whose code
> is granted the said permission has been marked as "privileged" (see below) and all
> parties subsequently called by this caller (directly or indirectly) all have the
>said
> permission.
> Marking code as "privileged" enables a piece of trusted code to temporarily enable
> access to more resources than are available directly to the code that called it.
>This is
> necessary in some situations. For example, an application may not be allowed direct
>access
> to files that contain fonts, but the system utility to display a document must
> obtain those fonts, on behalf of the user. In order to do this, the system utility
> becomes privileged while obtaining the fonts.
>From the documentation on Domain combiner:
>A DomainCombiner provides a means to dynamically update the ProtectionDomains
>associated
>with the current AccessControlContext.
>A DomainCombiner is passed as a parameter to the appropriate constructor for
>AccessControlContext. The newly constructed context is then passed to the
>AccessController.doPrivileged(..., context) method >to bind the
>provided context (and associated DomainCombiner) with the current execution Thread.
>Subsequent calls to
>AccessController.getContext or AccessController.checkPermission cause the
>DomainCombiner.combine to get invoked.
Joel Crisp, Senior Java Architect, SUN PS Java Center.
Rickard Öberg wrote:
>
> Hey
>
> Joel Crisp wrote:
> > It applies to the thread used by the EJB container. So any classes methods
> > called by that thread will be restricted. You need to pass an asyncronous
> > request to a thread outside the EJB container to access this functionality.
>
> This is not correct. It is related to ClassLoaders as outlined in my
> previous posts. If it was related to the thread then..
>
> > There was a discussion on one of the EJB lists about the use of doPriviliged()
> > at container level to relax this restriction for 'system' code.
>
> .. this wouldn't work.
>
> Calling doPrivileged does you no good if you don't have the desired
> Permission. And if the restrictions was related to the thread you
> wouldn't have the Permissions, so the mentioned discussion would be
> void. But it isn't, so you're incorrect :-) How's that for deduction...
>
> /Rickard
>
> --
> Rickard Öberg
>
> @home: +46 13 177937
> Email: [EMAIL PROTECTED]
> Homepage: http://www-und.ida.liu.se/~ricob684
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
