[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] principal based permissions in osgi


I went ahead and released the FrameworkSecurityManager patch provided by Ben so that progress can be made with Principal base conditions.  There was one thing wrong with the PrinicipalCondition implementation.  The static getInstance method should really be getCondition.  Attached is a working PrincipalCondition implementation.



Tom





Benjamin Reed <breed@xxxxxxxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

09/17/2005 11:52 PM

Please respond to
Equinox development mailing list

To
equinox-dev@xxxxxxxxxxx
cc
Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>
Subject
Re: [equinox-dev] principal based permissions in osgi





Here is a patch to FrameworkSecurityManager and an implementation of
PrincipalCondition. Subject.doAsXXX() methods function as normal. Principal
to Permission bindings are done through ConditionalPermissionAdmin. For
example, a ConditionalPermissionInfo of the form:

[...BundleLocationCondition http://www.ibm.com/-]
[...PrincipalCondition SuperMan]
(java.security.AllPermission)

says that when classes from a bundle from www.ibm.com are run with SuperMan
set as the current Subject, they will have AllPermission.

Initial tests (thanx Pascal) indicate that it's working.

One thing (of many) to remember when playing with JAAS is that
Subject.doAsXXX() is a glorified AccessController.doPrivileged(). The biggest
outcome is that a Subject (and it's principals) get associated with a new  
AccessControlContext. A subtle effect of this is that if a doPrivileged is
done inside of a doAsXXX() the new AccessControlContext setup by the
doPrivileged will lose the Subject.

The current AccessControlContext (ACC) can be extracted using
SecurityManager.getSecurityContext(), passed around, and evaluated directly
using SecurityManager.checkPermission(Permission, Object). It is for this
reason that PrincipalCondition needs to get a reference to the ACC being
checked, since it may not be the same as the one returned from
AccessController.getContext().

The attached patch adds a method for the PrincipalCondition to get the ACC
being evaluated so that we can get the Subject of correct ACC. Because
PrincipalCondition depends on a SecurityManager that has the added methods,
the implementation of PrincipalCondition is not portable (it cannot be run on
other OSGi implementations). It would be nice to standardize a way for
Conditions to get the ACC being evaluated. If in the future DomainCombiners
are used in other ways, corresponding conditions would also need the ACC.

ben

On Thursday 15 September 2005 12:00 pm, Pascal Rapicault wrote:
> Hi,
>
> Lately I've been looking at JAAS and its capability to dynamically
> associate permissions based on principals (usually declared in a policy
> file) and from that to use Subject.doAsPriviledged.
> Given that OSGi has its own way of expressing permissions, I would like to
> understand how principal based permissions can be declared.
>
> Thank you,
>
> PaScaL
[attachment "FrameworkSecurityManager.patch" deleted by Thomas Watson/Austin/IBM] [attachment "PrincipalCondition.java" deleted by Thomas Watson/Austin/IBM] _______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Attachment: PrincipalCondition.java
Description: Binary data