Security Changes - rethinking Scope and Permission

[Eric Dobbs <er...@dobbse.net>]

Hi All.

I'm rethinking Scope and Permission after trying to
answer the most recent questions from Chris Holman and
Peter Lynch.

Java's Permission object already accounts for the
Scope.  For example, java.io.FilePermission:

<http://java.sun.com/j2se/1.3/docs/api/java/io/FilePermission.html>

In a plain Java policy file, I would grant a chunk of
code permission to read and write from /your/path/here
with the following statement:

grant codebase "foo" {
   permission java.io.FilePermission "/your/path/here",
                                     "read,write";
}

Obviously, "/your/path/here" is the Scope, and
"read,write" is the Permission being granted.  Until I
looked back at these details, I had forgotten that a
java Permission object is a type of permission and not
the specific permission itself.

When granting most permissions, you specify a "name"
and "actions" for the granted permission.  How the
"name" and "actions" are interpreted depends on the
class.  Often, the name is used to denote scope and the
actions are what is being permitted within that scope.

Here's the map I've made between Turbine and JAAS:
     grant
          codebase TURBINE_GROUP
          Principal TURBINE_ROLE {
              permission TURBINE_PERMISSION;
     }

In light of my review of permissions, this is a much
better map:
     grant
          codebase SomeCodeBase
          Principal TURBINE_ROLE {
              permission o.a.t.security.Permission
                  TURBINE_GROUP, TURBINE_PERMISSION(s);
     }



On Thursday, February 14, 2002, at 08:56  AM, Chris Holman wrote:

> But, I have a problem getting my head round why CodeSource
> and Scope should be treated in the same manner.

Chris, I think there's good reason for why that's hard
to get your head around.  I just had it wrong. 8^)  I'm
guessing that the above mapping would make it easier to
create a JAAS implementation of Turbine 2 security.  I
don't think this removes this problem:

On Thursday, February 14, 2002, at 08:15  AM, Eric Dobbs wrote:

> In Turbine 2, the Scope (TURBINE_GROUP) is not included
> when Permissions are granted to Roles.  Intead, the Scope
> is included when Users assigned to Roles.  The ingredients
> are all there, but the order of operations are probably
> important.


Peter, your comments are what reminded me to look at
Java permissions (independent of the JAAS
conversation).  The "capability" notion you presented
sounded a lot like what Java permissions already
offer.


Gonzalo, I've now talked myself into a part of your
original code, though I'm renaming the method:

     SecurityManager.isPermitted(Subject,Permission);

(because instances of Permission will contain their own
Scope)

I'll try to rework the code in my proposals directory
to reflect these things in the next few days.

-Eric


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>