[
https://issues.apache.org/jira/browse/JSPWIKI-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18138261#comment-18138261
]
ASF subversion and git services commented on JSPWIKI-129:
---------------------------------------------------------
Commit 1b54e256c4fbdcf02b85e1264160e6fd59271541 in jspwiki's branch
refs/heads/dependabot/maven/tomcat.version-11.0.27 from Arturo Bernal
[ https://gitbox.apache.org/repos/asf?p=jspwiki.git;h=1b54e256c ]
JSPWIKI-129 Do not rely on the Java security manager to check permissions
Permissions were checked with AccessController.checkPermission inside a
Subject.doAsPrivileged, which consults the security policy of the JVM, and the
<groupmember> grant found the user in the access control context of the thread.
Both belong to the Java security manager, which is deprecated for removal and,
as
the test of <groupmember> already had to be skipped on JDK 25, stops working.
The permission of a session is now checked against the policy of the wiki only,
for the roles and the principals of the session. A GroupPermission that is not
granted as such is checked again as the <groupmember> of its group, through the
new GroupPermission.toMemberPermission, when the session's Subject is a member
of
that group. This is the same result as before for a wiki policy.
The policy of the JVM, set with java.security.policy, is not consulted anymore:
what it granted to a Subject also counted before, and a JVM policy that granted
too much made every user pass. Permissions that were granted to wiki roles in it
have to be in the policy file of the wiki, which UPGRADING says.
Also removed: the warning of the servlet filter about the security manager, the
verification against the JVM policy in SecurityVerifier,
GroupPermission.impliesMember
and jspwiki-container.policy, which was for running under a security manager.
Session.doPrivileged is deprecated.
> JSPWIki cannot run under a security manager
> -------------------------------------------
>
> Key: JSPWIKI-129
> URL: https://issues.apache.org/jira/browse/JSPWIKI-129
> Project: JSPWiki
> Issue Type: Bug
> Components: Authentication & Authorization
> Affects Versions: 2.4.104, 2.6.0, 2.6.1, 2.6.2, 2.6.3, 2.6.4, 2.8, 2.8.1,
> 2.8.2, 2.8.3, 2.8.4
> Environment: All
> Reporter: Andrew R. Jaquith
> Assignee: Andrew R. Jaquith
> Priority: Major
> Labels: pull-request-available
> Fix For: 3.0.1
>
>
> JSPWiki cannot be used when running a security manager. Containers that run
> by default with a security manager include Oracle Application Server and
> Tomcat when run with the '-server' option.
> In all cases, the root cause is the same: the security policy for the
> container needs to include the Permissions needed to execute JSPWiki.
> However, full enumeration of the Permissions needed is complicated
> significantly by the fact that JSPWiki does not compartmentalized privileged
> calls the way it should. For example, any code in JSPWiki that accesses files
> should be enclosed by AccessController.doPrivileged() blocks.
> The result of our current approach (or rather, lack of privileged code
> compartmentalization) means that an effective policy cannot be written.
> This bug is to remind ARJ that he needs to work on this. He is currently
> writing some diagnostic tools that will make this process easier. However,
> it's going to take a while...
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)