Hey
Alain Rogister wrote:
> > Generally speaking, I would not do this. Instead I would package this
> > kind of functionality in a separate library that is available to the
> > beans, but not through the classpath of the EJB-jar, but rather through
> > the system classloader or similar. As has been noted in earlier posts,
> > the classloader is the key to avoiding the restrictions of EJB.
>
> I remember you've explained in earlier threads that the classloader was
> the key, but I couldn't ever find any confirmation of this either in the
> EJB spec or from the spec's authors. Could you please provide us with
> the source of your explanation ?
Ok. The EJB restrictions rely on the Java2 Security API, which is based
on the concept of Permissions. So, to understand the restrictions, and
how to "avoid" them you need to understand that API first. This is not
trivial, and has taken me lots and lots of time to digest. The biggest
reason I looked this up in the first place is because I'm currently
implementing mobile agents on top of J2EE (really cool, and works well
too), which introduces a lot, no make that *A LOT*, of security issues.
Anyway, Permissions are given to classes by creating Policy objects, and
the default implementation is one that reads the
/lib/security/java.policy file. It would be a good idea for you to look
in it at this point.
Done?
As you can see there are a number of "grant" statements. The key to
getting around the EJB restrictions is to grant the permission that you
need, for example file I/O, to the classes doing the actual I/O. One way
to do this, as you can see in the policy file, is to simply put them in
the /lib/ext dir, as they will then be given the AllPermission
permission, which lets them do anything.
This is where the classloaders come in. If a classloader loads the
classes from a place which has been granted the necessery Permissions,
through the Policy, then those classes may be used by EJB's (which do
not have those Permissions as they were loaded from elsewhere) and
perform any nasty tasks such as socket usage, file I/O or similar.
But simply having the permission is not enough. Oh no, the security
permission checks are much tougher than that. They will check so that
*every class* in the stack has the needed permission. So even if the
class that does the call has a needed permission, it might be used by a
class that do not, and hence the security check will fail and throw a
SecurityException.
This is where the doPrivileged actions come into play. You see the
security check looks at all classes on the call stack to see that
everyone has the required permissions, *unless* it encounters a
doPrivileged use, in which case it stops the check and permits the
desired action (provided that all classes up until the doPrivileged call
are ok). Hence, even if the class that invoked the class that used
doPrivileged does not have the required permission, the operation will
pass without error.
And that's the whole story, or as close to it that I know.... *phew* R U
with me? :-)
Conclusion:
Wanna use I/O or other restricted operations?
* Put those calls in a separate "library" class
* Wrap "dangerous" sections in doPrivileged calls
* Package the classes separately
* Put the library on the classpath somewhere, so that the server can
access the classes
* Grant the desired permissions (AllPermission works well :-) to the
library
* Call the library from your EJB's
Or:
* Turn off security checks in the EJB-server if possible... not
recommended...
Disclaimer:
As always, I'm a theoretical kind of guy so all of the above are only
logical deductions from the tons of documentation that I've read: I have
not tested any of it in practice, so it might be completely off track.
/Rickard
ps. Is it time for a EJB-INTEREST FAQ soon? >:-)
--
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".
