# Group maintenance after ACL permissions have been set

Gary J. Braswell (rapidobj@mindspring.com)
Mon, 10 May 1999 11:39:21 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Jeff Nisewanger: "Re: SSL support in Appletviewer"
- Previous message: Massimo Bigliardo: "SSL support in Appletviewer"
- Next in thread: Gary J. Braswell: "Re: Group maintenance after ACL permissions have been set"

    From: "Gary J. Braswell" <rapidobj@mindspring.com>

    To: <java-security@java.sun.com>

    Subject: Group maintenance after ACL permissions have been set

    Date: Mon, 10 May 1999 11:39:21 -0400

------=_NextPart_000_0012_01BE9AD9.BECF9B10
Content-Type: multipart/alternative; boundary="----=_NextPart_001_0013_01BE9AD9.BECF9B10"
X-Sun-Content-Length: 4705

------=_NextPart_001_0013_01BE9AD9.BECF9B10
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I made a simple modification to the AclEx.java file that was posted =
under the URL =
http://www.javasoft.com/products/jdk1.1/docs/guide/security/Acl.html, =
and it presented a problem for me.

I moved the addition of user2 until after the group had been added to =
the access control list. The logic here is that a Security =
Administrator is going to want to be able add users to an established =
group that already has a certain set of permissions (e.g., relationships =
with Acls), and have that user "inherit" (not from the OO standpoint) =
the permissions that already exists for the group.

When I moved the "g.addMember(p2);" line until after the group had been =
added to the Acl, the p2 principal did not receive any of the group =
permissions.

I'm not sure why this wouldn't work. =20

The Access Control List acl should have a valid reference to the =
modified GroupImpl g (e.g., with the newly added p2). The only reason =
that it would fail is if the Acl calculates permissions only upon its =
instantiation or in a modifier method.=20

Wouldn't it need to go out to its group constituents and refresh the =
member list when a checkPermissions() call is made?

I've attached the source code for your review.

Thanks in advance for any help with this. If you know of another way to =
accomplish what I'm trying to do, please advise.

Regards,
Gary J. Braswell
Sr. Software Engineer, Syndesa Corporation

------=_NextPart_001_0013_01BE9AD9.BECF9B10
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
I made a simple modification to the = AclEx.java=20 file that was posted under the URL http://www.javasoft.com/products/jdk1.1/docs/guide/security/Acl.html= ,=20 and it presented a problem for me.
I moved the addition of user2 until = after the=20 group had been added to the access control list. The logic here is = that a=20 Security Administrator is going to want to be able add users to an = established=20 group that already has a certain set of permissions (e.g., relationships = with=20 Acls), and have that user "inherit" (not from the OO = standpoint) the=20 permissions that already exists for the group.
When I moved the = "g.addMember(p2);"=20 line until after the group had been added to the Acl, the p2 principal = did not=20 receive any of the group permissions.
I'm not sure why this wouldn't = work. =20
The Access Control List acl should = have a valid=20 reference to the modified GroupImpl g (e.g., with the newly added = p2). The=20 only reason that it would fail is if the Acl calculates permissions only = upon=20 its instantiation or in a modifier method.
Wouldn't it need to go out to its = group=20 constituents and refresh the member list when a checkPermissions() call = is=20 made?
I've attached the source code for = your=20 review.
Thanks in advance for any help with = this. =20 If you know of another way to accomplish what I'm trying to do, please=20 advise.
Regards,
Gary J. Braswell
Sr. Software Engineer, Syndesa=20 Corporation
------=_NextPart_001_0013_01BE9AD9.BECF9B10-- ------=_NextPart_000_0012_01BE9AD9.BECF9B10 Content-Type: application/octet-stream; name="AclEx.java" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="AclEx.java" X-Sun-Content-Length: 3197 /* Note: This sample program is meant just as an example * of the types of things that can be done with an * implementation of the java.security.acl interfaces.=20 * This example uses the implementation supplied by the=20 * sun.security.acl package. Please note that sun.* classes=20 * are unsupported and subject to change. */ package CCSecurity; import java.security.Principal; import java.security.acl.*; import sun.security.acl.*; import java.util.Enumeration; public class AclEx { public static void main(String argv[]) =20 throws Exception { Principal p1 =3D new PrincipalImpl("user1"); Principal p2 =3D new PrincipalImpl("user2"); Principal owner =3D new PrincipalImpl("owner"); =20 Permission read =3D new PermissionImpl("READ"); Permission write =3D new PermissionImpl("WRITE"); =20 System.out.println("Creating a new group with two members: user1 and = user2"); Group g =3D new GroupImpl("group1"); g.addMember(p1); // g.addMember(p2); =20 //=20 // create a new acl with the name "exampleAcl"=20 //=20 System.out.println("Creating a new Acl named 'exampleAcl'"); Acl acl =3D new AclImpl(owner, "exampleAcl");=20 =20 //=20 // Allow group all permissions=20 //=20 System.out.println("Creating a new Acl Entry in exampleAcl for the = group, "); System.out.println(" with read & write permissions"); AclEntry entry1 =3D new AclEntryImpl(g);=20 entry1.addPermission(read);=20 entry1.addPermission(write);=20 acl.addEntry(owner, entry1);=20 =20 //=20 // Take away WRITE permissions for =20 // user1. All others in groups still have=20 // WRITE privileges.=20 //=20 System.out.println("Creating a new Acl Entry in exampleAcl for = user1"); System.out.println(" without write permission"); AclEntry entry2 =3D new AclEntryImpl(p1);=20 entry2.addPermission(write);=20 entry2.setNegativePermissions();=20 acl.addEntry(owner, entry2); =20 =20 //=20 // This enumeration is an enumeration of =20 // Permission interfaces. It should return=20 // only "READ" permission.=20 Enumeration e1 =3D acl.getPermissions(p1);=20 System.out.println("Permissions for user1 are:"); while (e1.hasMoreElements()) { System.out.println(" " + e1.nextElement()); }; =20 //=20 // This enumeration should have "READ" and"WRITE" =20 // permissions.=20 Enumeration e2 =3D acl.getPermissions(p2);=20 System.out.println("Permissions for user2 are:"); while (e2.hasMoreElements()) { System.out.println(" " + e2.nextElement()); }; // This should return false.=20 boolean b1 =3D acl.checkPermission(p1, write);=20 System.out.println("user1 has write permission: " + b1); =20 // This should all return true;=20 boolean b2 =3D acl.checkPermission(p1, read);=20 boolean b3 =3D acl.checkPermission(p2, read);=20 boolean b4 =3D acl.checkPermission(p2, write);=20 System.out.println("user1 has read permission: " + b2); System.out.println("user2 has read permission: " + b3); System.out.println("user2 has write permission: " + b4); } } ------=_NextPart_000_0012_01BE9AD9.BECF9B10--

- Next message: Jeff Nisewanger: "Re: SSL support in Appletviewer"
- Previous message: Massimo Bigliardo: "SSL support in Appletviewer"
- Next in thread: Gary J. Braswell: "Re: Group maintenance after ACL permissions have been set"