On Fri, 10 Jan 1997, Anselm Baird_Smith wrote:
> I guess I am latenot uptodate on that subject, but here is roughly
> what I had in mind (in order to determine the permissions for a given
> resource). First of add some class loader handling in the
> ResourceStore API: all resources loaded from a given resource store
> would use that instance of a class loader, so each resource would have
> a (new) getClassLoader() method - that might return null.
>
> This per-resource class loader, would then be passed through to
> children, for container resources: if directory D was loaded through
> class loader C, then any children of D would be loaded through that
> same class loader.
>
> Security permissions would be indicated within that class loader; and
> the Jigsaw Security manager would look for these bits in the class
> loader to determine what operation is granted to the resource, for
> example:
>
> JigsawSecurityManagerImplementation
> implements JigsawSecurityInterface
> {
>
> public boolean checkResourceStoreAccess(SecurityManager sm
> , File resourcestorerepository)
> throws SecurityException
> {
> ClassLoader cl = sm.currentClassLoader();
> if ( ! cl.checkResourceAccess(resourcestorereposirory) )
> throw new SecurityException();
> }
> }
>
> Then the std jigsaw security manager would look like:
>
> JigsawSecurityManager extends SecurityManager {
> JigsawSecurityManagerImplementation impl ;
>
> public boolan checkResourceStoreAccess(File repository) {
> impl.checkResorceStoreAccess(this, repository);
> }
> }
>
> Does this makes sense ? The thing I am missing from both Alexander and
> Alex is why is some binding to threads needed here ?
Anselm,
I would like to restate your model just to be clear:
Your idea is that we design a classloader for each permissions profile.
Since each resource is loaded from a particular classloader or null if the
resource class was defined in the local filesystem, the
JigsawSecurityManager simply checks the current classloader (the one that
the particular resource used) and applies permissions based on that
classloader.
The reason why I assumed that thread binding was necessary is that the
servlet documentation indicated that they were going to implement the
JeevesSecurityManager via threadgroups.
I am new to classloader issues so please correct me if I am mistaken.
Isn't this structure vulnerable to calls to Static methods of classes
loaded via other classloaders?
I'm also not sure that the classloader model makes sense because I would
have thought that permissions shouldbe determined by path as well as
class. E.g. instances of a Resource behind an auth filter may have
different permissions than instances accessible anonymously.
I suppose that the same class can get loaded by different classloaders,
but that seems inefficient.
It seems more efficient to be able to lookup the resource and discover
its security manager.
Ideally the permissions for a sandboxed Resource would depend on three
things:
1. The source of the class
2. the path to the class
3. the particular user at the time.
For example, suppose I wanted to write a web based file manager that
allowed me to use the web to move files on my servers file system.
The system might involve a few different resources that all provided
web based analogs of unix functionality. Rather than having each resource
that accesses the filesystem implement some security checking
functionality, I would prefer to embed that functionality in a single
place. A security manager that mapped auth users to users of the local
unix system would help a lot.
To be very precise, suppose that I wanted to allow users to add file
utilities. They should all have access to the file system, but all these
resources would need security checks.
Doing that requires that the security manager is able to obtain
information from filters and resources that are participating in a
particular request as well as knowing which classloader was the source of
the particular resource.
Does this make sense?
-Alex-
_____________________________________________________________________________
S. Alexander Jacobson Interband Communications
1-212-799-2645 voice 1-212-799-1075 fax