[
https://issues.apache.org/jira/browse/COLLECTIONS-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14250738#comment-14250738
]
Trejkaz commented on COLLECTIONS-538:
-------------------------------------
I think the situation is that the application has permission to read system
properties anyway, but it's evaluating some JavaScript at some point.
The script being down somewhere in the stack means that the entire stack is
treated as unprivileged. I don't know if there is a way around that... I
couldn't immediately see any APIs around ScriptEngine or ScriptContext which
allowed me to set the privileges for the script. The script itself is running
is from the same directory as the rest of our code, so it should presumably
have had the same privileges as everything else, but for whatever reason, I
guess script engines don't work like that.
What I might do is fork the project into our local repo and make the change
just for our copy.
> ExtendedProperties causes AccessControlException when framework is called
> from a script
> ---------------------------------------------------------------------------------------
>
> Key: COLLECTIONS-538
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-538
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
> Affects Versions: 3.2.1
> Environment: Java security manager enabled
> Reporter: Trejkaz
>
> We're using Velocity 1.7, which depends upon Commons Collections 3.x series'
> ExtendedProperties class.
> ExtendedProperties has these constructors where it looks up the file
> separator using the least convenient means possible:
> {code}
> public ExtendedProperties() {
> this.fileSeparator = System.getProperty("file.separator");
> // ...
> }
> {code}
> For us, this is all being called from untrusted code, so this fails with
> AccessControlException.
> I think that instead of using the system property here, it is customary to
> use the File.separator constant.
> If you absolutely _must_ use System.getProperty() to fetch this value, it
> should at least be done from a doPrivileged() block.
> Also I had a quick check of Commons Collections 4 to see if this issue had
> been fixed, but couldn't immediately see what happened to this class. If it
> did turn out to have been fixed in v4, maybe Velocity could be encouraged to
> update to v4, but I haven't seen any updates from them in 4 years, so it's
> probably not a good sign.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
