Development set up AccessControlException: Access denied #169
Comments
|
This error looks like it is coming from the java security policy used for sandboxing student answers. It looks like we need to fix that in the development setup. For a dev setup, the quickest workaround is to remove the security policy enforcement. Of course, don't do that for a publicly available instance, but it is ok for a local dev instance that is not externally accessible. Can you try this to see if it fixes the problem? Look in the usr/resources/config.rb file, and find the CMD[java][cmd] variable, and comment out/remove the two lines for -Djava.security.manager and -Djava.security.policy (lines 30-31 in the master branch here on github). Then try again and see if this error goes away. If that fixes the problem, re-enabling the security policy likely means looking at usr/resources/Java/java.policy and figuring out which item needs fixing. You can look at the raw Java exception trace in the output (look in your usr/attempts folder and find the folder for your failed attempt and look at the raw files there). That exception trace should give you an indication of which code caused the security violation. I'm guessing it was a standard Java library, though. From there, look at the grant clauses on lines 22-35 in usr/resources/Java/java.policy that cover the jvm and revise/add the grants to cover where the JVM standard libraries are installed in your dev setup. I think that is probably the issue (not sure, so confirmation is useful). Ayaan, we need to fix this in the committed version of java.policy so that this error doesn't occur in the docker container. |
|
The command looks ok |
has no special grants and it seems creating a new instance : So what should I do add the getProtectionDomain Permission ? How is it solved in your set up? I don't yet see what it has to do with docker:thinking: But maybe I don't understand good enough what is going on. |
|
I went ahead and added that permission and now it works at least for the Factorial Exercise. Is adding the permission the intended solution? Should it be applied to the staging branch? |
|
That grant should not be necessary--it should be covered by one of the other grants that is already in the java.policy file. I'm still thinking that the problem is one of the existing grants in java.policy that uses variable expansion is not working as intended (which is why there are a number of grants that use hard-coded path names instead), and that the JVM install location in your instance isn't covered by one of those because the path is wrong. No questions should ever need specific grants of the nature you've added in this workaround, and indeed they don't on our production instance, or staging instance, or my dev instance. |
|
The jdk is found there: And there is a But anyways if my understanding of the permission system is correct then the Class that has the lowest permissions on the stack trace is the one that decides on whether an action is legal. Hence the jdk location should be irrelevant. And the permissions on FactorialTest relevant. The question for me is why does the AntClassLoader call Class.getProtectionDomain on loading the class, he does not do that in your setup (Otherwise it should fail there as well) then it seems so maybe it is cause I got a newer Ant version or java version 🤔 |
on the other hand I am not sure if the AntClassLoader comes from the ant.jar in the usr/resources/Java folder |
|
The ant classes should be in your ANT_HOME's lib directory. The java.policy file grants permissions using the ${ant.home} system property, which normally would be set by ANT when it is running. It is plausible that the ${resource_dir} grant may be the issue instead, but I'm not sure. To debug this, you can also use the alternative security manager, take a look at the alternate launch command shown in usr/resources/config.rb on lines 16-24. Pay attention to lines 18-19, which show an alternate security manager setup: You can temporarily use that version of the Java command, and edit the output destination to the file name/location of your choice. It will replace the security manager with one that will actually not block permissions, but will dump the missing grants needed to make the permissions work. It's not perfect, but it can confirm what is missing a grant that matters in order to try to narrow the problem down. I'd jump in and debug it for the docker launch, but this week there are two major conferences going on (ICER starts today, and L@S starts later this week) plus a conference paper deadline this weekend, plus the start of classes looming, so it will be a bit of time before I can try it myself. The profiling security manager will get you up and running, and allow you to fix the grant issue in parallel instead of making it a blocking issue. |
|
Don't worry I got a lot of time till the semester starts :D We start 1.November |
|
Also me adding to the grant for all fixes it so it is not blocking. I just wanted to figure out what is actually wrong so I could potentially make a PR and rule that issue out. |
|
Using the debug set up I only get the following out put in the err.log file: No security.txt No ant.log nothing anywhere. Not even sure if this is really an error 😅 |
|
Hmmm ... I see what you did. Yes, adding that to the main grant should be fine as a fix for this. For the debugging security manager, the useful output would go in the specified output file (as written, that's security.txt in the CWD in which the process executes, but you can change that to use a fully qualified pathname to a location where you know permissions are ok--the default would go inside the docker image, if you're using a docker dev instance). Also, I noticed the regular cmd value includes a -D for ant.home on line 27, and if ANT_HOME isn't defined as an env variable, that may cause the grant for ANT jars to fail to be meaningful. IIRC, the reason that -D is there is because ANT sets this property, but I believe the security manager takes effect at JVM launch, which means the java.policy file is processed before ANT begins running, so ant.home is not yet defined by ANT when the policy file is loaded. Which JVM version are you using? |
|
👌 |
Setup: Followed steps in the read me
When executing tests on a development set up:
AccessControlException: Access denied ("java.lang.RuntimePermission" "getProtectionDomain") is thrown
The text was updated successfully, but these errors were encountered: