Greetings Daniel, For the sake of discussion, I will look at these classes as classifiable into two groups: classes that we use (or are useful) only in the context of a security manager, and classes that we use (or are useful) independently of any other JDK API.
I would put all three of these classes (`NetPermission`, `URLPermission`, and `SocketPermission`) in the former category, as well as the other non-`AllPermission` classes listed in Sean's PR: we (and our users) would use them only in the context of a security manager, so when that is gone, our need to support these classes goes with it, as far as I can tell. The classes that we would continue to require on an ongoing basis (to my knowledge) would include `Permission` itself (obviously), `AllPermission`, and the `BasicPermission` base class (which also seems to be subclassed by many third-party projects). On Fri, Apr 4, 2025 at 10:05 AM Daniel Fuchs <daniel.fu...@oracle.com> wrote: > Hi David, > > Are there other subclasses of Permission that this framework uses? > More specifically - would it be fine to deprecate NetPermission, > URLPermission and SocketPermission classes? > > best regards, > > -- daniel > > On 04/04/2025 15:51, David M. Lloyd wrote: > >> Can you elaborate or give an example/pointer to code on how it uses > `AllPermission` w/o the corresponding SM APIs and infrastructure (policy > files, `AccessController`, etc)? > > > > The [`wildfly-elytron`]( > https://github.com/wildfly-security/wildfly-elytron) project uses > `Permission` and `PermissionCollection` as a standalone basic API to > represent user authorization permissions. Some examples include > `LoginPermission` and `RunAsPrincipalPermission`, and a special > `NoPermission` class which is useful in certain situations. > > > > The user authorization mechanism does not use policy files, security > manager APIs, `AccessController` or any other JAAS-adjacent API for this > purpose. > > > > Security contexts are managed completely separately from the JDK using > thread local scoping (planned to move to `ScopedValue` someday if/when it > becomes available). Permissions are checked against the user security > context (`org.wildfly.security.auth.server.SecurityIdentity`) by > authorization-sensitive operations in both server and user code. > > > > The `AllPermission` class is used for "superuser" authorization > situations, and cases where the deployer opts out of authorization checks > for whatever reason (for example, testing). We use it for role-based access > control of the application server itself when access control checks pass, > as well for superuser authorization cases, and probably other cases I'm > forgetting about (it's one of those things that we always assumed would > stick around forever, so we used it without a second thought). > > > > `AllPermission` is an integral concept of permission sets, and thus we > would be obliged to create our own if the JDK one disappeared, causing > compatibility problems due to the class moving to a new package from the > point of view of consumers. Its destiny should be tied to that of > `Permission` itself in my opinion, because it is pretty fundamental. > > > > ------------- > > > > PR Comment: > https://git.openjdk.org/jdk/pull/24445#issuecomment-2778956492 > > -- - DML • he/him
