• Post Reply Bookmark Topic Watch Topic
  • New Topic

trying to understand SecurityManager  RSS feed

 
Alan Shiers
Ranch Hand
Posts: 237
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Guys,

I'm trying to wrap my head around this SecurityManager class and how I can create a subclass of it so it will have an impact on plugins for my larger project. But in just trying to understand the basics I came across an unusual phenomenon. Unusual to me anyway. Please see test code below. I wrote a test class that attempts to write a file to somewhere on the hard drive. In the constructor I either load up the default SecurityManager class from the System or I load my own MySecurityManager which simply calls the super.checkRead and super.checkWrite methods from the parent class SecurityManager. One would expect that going either way would have the same result. But Nooooo! If I load up the default SecurityManager by calling sm = System.getSecurityManager(); then I'm able to write the file as expected. When I instead load up MySecurityManager with sm = new MySecurityManager(); or sm = new SecurityManager() then I get the AccessControlException. What gives? I don't understand. Why is the call to super.checkWrite(...) throwing the exception? Please advise.

Alan

c:\Temp>java TestManager
Exception in thread "main" java.security.AccessControlException: access denied
java.io.FilePermission C:\Jars\goodFile.txt read)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkRead(Unknown Source)
at TestManager$MySecurityManager.checkRead(TestManager.java:43)
at java.io.File.exists(Unknown Source)
at java.io.Win32FileSystem.canonicalize(Unknown Source)
at java.io.File.getCanonicalPath(Unknown Source)
at sun.security.provider.PolicyFile.canonPath(Unknown Source)
at java.io.FilePermission$1.run(Unknown Source)
at java.io.FilePermission$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.io.FilePermission.init(Unknown Source)
at java.io.FilePermission.<init>(Unknown Source)
at java.lang.SecurityManager.checkWrite(Unknown Source)
at TestManager$MySecurityManager.checkWrite(TestManager.java:47)
at java.io.FileOutputStream.<init>(Unknown Source)
at java.io.FileOutputStream.<init>(Unknown Source)
at java.io.FileWriter.<init>(Unknown Source)
at TestManager.writeFile(TestManager.java:28)
at TestManager.main(TestManager.java:12)

See test program:

 
Paul Clapham
Sheriff
Posts: 22819
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alan Shiers wrote:One would expect that going either way would have the same result.


Why would one expect that? Is that expectation based on something you read somewhere, or was it based on an assumption you made?

If it's the former, then it would be interesting for us to read what you read, to see what's up. But if it's the latter, then you should proceed by deciding your assumption was incorrect.

I'm guessing it's the latter. In which case the next reasonable assumption to be made would be that your SecurityManager allows the program no access to anything unless it's specifically coded in the SecurityManager. But personally, at this point I would give up on assumptions and look for tutorials.
 
Alan Shiers
Ranch Hand
Posts: 237
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why would one expect that? Is that expectation based on something you read somewhere, or was it based on an assumption you made?

If it's the former, then it would be interesting for us to read what you read, to see what's up. But if it's the latter, then you should proceed by deciding your assumption was incorrect.

I'm guessing it's the latter. In which case the next reasonable assumption to be made would be that your SecurityManager allows the program no access to anything unless it's specifically coded in the SecurityManager. But personally, at this point I would give up on assumptions and look for tutorials.


Allow me to back up a bit. I've been researching this whole business of adding a SecurityManager because I'm working on a project that will include the use of plugins. Since plugins may be written by third parties, one would be wise to implement a SecurityManager to enforce certain policies. One of the tutorials I came across was here on your own site: http://www.javaranch.com/journal/200607/Journal200607.jsp#a1

This tutorial is a bit dated and I tried to rewrite it so I wasn't getting any deprecation errors, while at the same time, trying to update it in accordance to the current implementation of how SecurityManager works, which for me is a limited understanding based on what I've read in the JavaDocs and elsewhere. The process has not been an easy one. I think I've become confused based on the old way SecurityManager used to work and how it works now. In either case, I was lead to believe that if a main application were to read or write to a file, a SecurityManager would allow it. But if some code from another source (such as a plugin) were to attempt the same thing, the SecurityManager would disallow it.

When I ran my test program the results confused me even more. Why would the default SecurityManager from the System.getSecurityManager() call allow the app to write a file when the other two wouldn't?

Since I've made the original post, I've continued to look for recent works on this subject, and am wondering if I'm going to have to implement my own java.security.Policy instance in order to enforce my own set of Permissions?

Alan

 
Paul Clapham
Sheriff
Posts: 22819
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What you call the "default" SecurityManager is actually only the default for Java applications. Applets have a different SecurityManager, and web applications have a different SecurityManager again. So you were expecting that your SecurityManager would inherit all of the features of the SecurityManager for Java applications, in other words "anything goes". But it looks like it might be the opposite: your SecurityManager is a completely fresh one which doesn't permit anything at all.

As for tutorials: if I recall correctly from ancient history, Java security was redesigned for Java 2, which was released in... (googling...) 1998. But security isn't a cool topic, so not many people write tutorials for it. That means that you're at risk of finding Java 1.1 tutorials (older pages have more links to them so Google finds them better) and it sounds like that's been happening to you.

I had a look at the API docs for SecurityManager and soon realized they were leading me into a swamp. I don't know why language designers make things so hard for implementers, it just makes people throw up their hands and implement insecure systems instead. But anyway if it were me I would start out with a simple SecurityManager which just overrode its methods to allow hard-coded things. And then go from there once you got more experience in the subject. Sorry to not be of much help, but I really don't want to wade into that swamp if I don't have to.

 
Alan Shiers
Ranch Hand
Posts: 237
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Paul. I appreciate your guidance thus far. If any one else has had experience with creating a class that extends SecurityManager, I'd appreciate any input you have to offer.

Alan
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!