[
https://issues.apache.org/jira/browse/JSPWIKI-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639299#action_12639299
]
Andrew Jaquith commented on JSPWIKI-345:
----------------------------------------
Ok -- I was able to confirm this bug, as written up. There are two issues here,
a bug and a documentation flaw.
First, the bug. The library JSPWiki uses (my own freshcookies-security library)
has its own clean-room policy file parser and a LocalPolicy class that allows
programs to parse and use security policies that aren't tied to the JVM policy.
LocalPolicy contains a flaw in its samePrincipals() method that causes it to
incorrectly compare generic principals specified in policy files.
Background: in J2SE policy files, Principals can be specified in two ways. The
most portable, but less secure way, is to specify non-class-specific principal
names -- such as what you specified above, and is in the docs example:
grant principal "Username"
Here, this grant means grant "any Principal whose name equals 'Username' the
privilege."
The other way is to use a specific class and principal name, e.g.:
grant principal com.ecyrd.jspwiki.auth.WikiPrincipal "Username"
In the latter case, not only must the Principal have the name 'Username' get
the privilege, but it must also be of type com.ecyrd.jspwiki.auth.WikiPrincipal.
LocalPolicy's samePrincipals() method *should* handle the first case (generic
Principal) gracefully, but it doesn't. So, at the moment the workaround for
this bug is to specify a fully-qualified Principal name, with class. If you
change your policy block to read:
grant principal com.ecyrd.jspwiki.auth.WikiPrincipal "Username"
...you will find that it works, I think.
This is a workaround until I can get a revised freshcookies-security library
out. That won't happen in the very short term, so I recommend you employ the
workaround until 2.8.1.
The documentation flaw is that we don't make the need to use the
fully-qualified Principal name clear. I've changed that on the docs site.
Sorry about this. The reason we haven't caught this flaw until now is that,
frankly, nobody writes policy files that grant permissions to named users. From
a security best practices perspective, it's not a good idea anyway.
Marking this as something for the 2.8.1 timeframe.
> Security Policy for a Single User
> ---------------------------------
>
> Key: JSPWIKI-345
> URL: https://issues.apache.org/jira/browse/JSPWIKI-345
> Project: JSPWiki
> Issue Type: Bug
> Components: Authentication&Authorization
> Affects Versions: 2.6.3
> Environment: Tomcat 6.0 on RHEL5.
> Reporter: Paul Edelman
> Assignee: Andrew Jaquith
> Priority: Minor
> Fix For: 2.8
>
>
> The procedure listed in
> http://doc.jspwiki.org/2.4/wiki/Security#section-Security-CustomizingJSPWikiSecurity
> regarding creating a security policy for an individual user does not appear
> to work. After having followed the instructions several times we are unable
> to grant specific access to an individual user in JSPWiki. To be certain
> that the changes had taken affected we did restart the application between
> changes. We are certain that the user existed and could login with other
> default permissions. We even removed all other custom policies to see if
> they were in conflict and added only the users policy. After attempting
> login for the given user none of the permissions granted to them in the
> policy had effect. The policy for the user was defined as such:
> grant principal "Username" {
> permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:*",
> "view, modify";
> };
> This is likely a matter of out dated documentation, or a misunderstanding of
> how to grant the principal. We later added a group principal for a group
> containing only the user and the permissions went into affect without any
> problems. We would rather like to not have to create a user and user group
> for each user we create that we want to give a special security policy to.
> Thanks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
