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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
