policy file problems

[khanh ng]

i keep getting the following error when i try to run my server. I have a policy file as follows:
grant {
permission java.security.AllPermissions;
permission java.net.SocketPermission"*:1024-65535","connect,accept,resolve";
permission java.net.SocketPermission"*:1-1023","connect,resolve";
permission java.io.FilePermission
"c://suncertify//server//db.db", "read,write";
};
Any ideas why i might still get the following error?
access denied (java.io.FilePermission C:\suncertify\server\db.
db write)
java.security.AccessControlException: access denied (java.io.FilePermission C:\s
uncertify\server\db.db write)
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.checkWrite(Unknown Source)
at java.io.File.canWrite(Unknown Source)
at suncertify.db.Data.<init>(Data.java:96)
at suncertify.server.Server.<init>(Server.java:16)
at suncertify.server.Server.main(Server.java:127)

[Dave Boden]

Sorry to spell out the obvious, but you are setting the java.security.policy attribute on the command line, aren't you?
This is what loads the policy file:
java -cp blahblah -Djava.security.policy="c:\mydir\mypolicy.policy" MyClassFile

[khanh ng]

I am setting the policy file on the command line, but I still get that error. Any other ideas?

[Nathan Daniels]

I think your problem is related with the backslash
You should have "c:\\suncertify\\server\\db.db instead. Try that

[khanh ng]

still having the same error. Any other suggestions?

[Conor Allen]

Hmmm ....
Are you sure that the db.db file is actually writeable?
Conor

[Sri Addanki]

Originally posted by Conor Allen:
Hmmm ....
Are you sure that the db.db file is actually writeable?
Conor

How to make sure that the database file is writeable

[Mark Spritzler]

CODE] grant {
permission java.security.AllPermissions;
permission java.net.SocketPermission"*:1024-65535","connect,accept,resolve";
permission java.net.SocketPermission"*:1-1023","connect,resolve";
permission java.io.FilePermission
"c://suncertify//server//db.db", "read,write";
};[/CODE]
I'd keep it simple and only have the first permission, AllPermissions. remove the rest. Not that that will solve your problem. One thing for your problem, are you using the RMISecurityManager? In the client or the server or both? Do not use it on the server.
Sri Addanki- You can always look at the file properties, in Windows Explorer, right-click and select properties, which I know you know how to do.
Mark

[Sri Addanki]

are you using the RMISecurityManager? In the client or the server or both? Do not use it on the server.
Hi Mark,
Thanks for the reply
but why shouldn't i be using RMISecurityManager on the server side? i have it on BOTH client and server side. i DID check the file properties from explorer and found that the database file has all permissions. But still i get the error. My policy file is like this
grant
{
permission java.security.AllPermission;
};
and as u said i'll try removing RMISecurityManager on server side and see....
Thanks again,
Sri

[Rajesh Matti]

Mark - Why should not the server have the policy file ? Would you please clarify.
Thanks,
-Rajesh

[Mark Spritzler]

Becuase it would be a rogue client that messes things up. The server is started by someone who is at the server, already logged on and has permissions to do whatever they please already.
That's why I only have it on the client side. Plus I got errors when it was on the server side, just like the ones posted here in this thread.
Mark

[Andrew Keidel]

Hi Mark,
First off, thanks for all your helpful comments in these newsgroups! As for the RMISecurityManager issue, I'm still struggling to find a definitive answer, but I disagree with your thinking that the client needs it instead of the server; my reason is similar to the one Farouk Mohamed1 gave in another thread (http://www.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=25&t=001489).
Here's the thing. If you are worried about ROGUE clients, then you need to protect for this on the server! It does not make sense to require clients to include code that prevents them from being rogues, since the whole idea of a rogue client is that he wouldn't follow this security guideline. The clients CAN access the db.db file on the server by calling the server's methods remotely. And as we know, locking/unlocking is called by the client (even though I think a better design would be to let only the server perform locking/unlocking on behalf of client write requests). What if a rogue client comes in and tries to lock the whole database? My impression is that we need to implement a security policy on the server so that we can block out such rogue clients.
The whole security policy issue seems to be one of the more vague topics concerning this assignment. Peter, I don't see any posts from you on this issue. Can you help us out?

[Mark Spritzler]

Andrew, yes. But if the client did not have an RMISecurityManager then it wouldn't be able to make any calls to the RMI Server.
Mark

[Andrew Keidel]

Not sure if this is true. My clients work fine without an RMISecurityManager. Maybe it has something to do with the default settings on my system.
I think one area where we were mislead is that the RMISecurityManager is not meant to protect the server from clients. It is meant to protect the clients from the server. Seems that it specifies what stub code can be downloaded and used from a server. If this is the case, and I think it is, then my last posting was misguided and it makes sense to use RMISecurityManager on the client.
Two questions I have are:
Is RMISecurityManager/policy file necessary for the client if we don't download stubs dynamically?
2. More basic: Are RMISecurityManager and security policy files two ways of doing the same thing?

[Michael Morris]

Hi Mark,
Correct me if I'm wrong (because I thought I finally had this straight in my mind) but you only need to install an RMISecurityManager if you are going to pass stubs (or possibly subclasses that are not in the local CLASSPATH) across the wire. So if you have the stubs in both client and server CLASSPATHs and you don't pass any other objects, then do you need to install an RMISecurityManager? Also wouldn't you have to install one on the server if you had an unknown class that extended some known class on the server that was passed by the client?
Thanks in advance
Michael Morris

[Andrew Keidel]

Hi Michael,
After some more research, my understanding is this. If machine A needs to dynamically load stubs from machine B, then machine A needs an RMISecurityManager. Once it has an RMISecurityManager, it will probably also need a security policy file to set the details right. Machine A can be either the client or server; although in our case it happens to be the client.
So far, I think that's exactly what you just said.
So since most of us are not dynamically passing stubs (wouldn't doing so require a webserver?), we do not need an RMISecurityManager. Thus, we don't need any policy file (neither for the client nor the server) to have a working application.
However, it is a "good" idea to have a policy file for the server anyway, just for the sake of restricting access to trusted clients. The difference is that the PURPOSE of this server security policy file would not be to allow stub downloading, but to restrict client access. As far as this safety net is concerned, however, I don't think it falls into the scope of the assignment.
Thoughts?

[Michael Morris]

Hi Andrew,
My experimenting with RMI sometimes leaves me more confused than convinced. I wrote a simple little RMI app (server & client) which only passes primitives. On Windows 2000, the server would only run with a policy file in place. Without it I got a SecurityException for attempting to open a Socket (I assume on port 1099 which is the default RMI port.) On Windows 98, I didn't need a policy file. In neither case did the client need a policy file. No RMISecrutityManager was needed on either end unless the stubs were not in the local CLASSPATH of the client, in which case the client then required the security manager.
Considering all of this I may just play it safe and put a security manager and policy file on both ends. After all wouldn't the design be better if the Remote stubs were only on the server? That way the implementation could change (of course you leave the interface intact) on the server and there would be no need to copy the new stubs to the client's local CLASSPATH.
Anyway, anyone's opinion or knowledge is greatly appreciated.
Michael Morris

[Mark Spritzler]

Anyway, anyone's opinion or knowledge is greatly appreciated.

To be honest I think you will find the easy way out is to only have it on the client. However, alot of times it takes experience with the crazy mess that this part is, and get frustrated and then go the easy way. At least that is what happened to me.
Maybe you will be able to figure out how to get it to work on both ends.
Mark

[Michael Morris]

Once again thanks Mark. If it's not too much trouble, would you look at my post on running the client in local mode and give me your expertise.
Thanks in advance
Michael Morris

[Andrew Keidel]

Hi Mark,
Thanks for your advice. My remaining question is:
If the client jar file that we submit contains the stub files (meaning we don't need dynamic downloading), is there any need for an RMISecurityManager on the client?
I believe the answer is no, since the purpose of an RMISecurityManager is to make sure the client does not download malicious remote code.
Do you agree?

[Mike Birken]

One strange thing that I noticed with the policy files is that RMI seems to run a lot faster if you use a policy file that sets all permissions (no security). More restrictive policy files seem to require more time to establish a connection and more time to transmit messages. I am running these tests under WinXP with Java1.3.1 and I made sure no errors are thrown using the more restrictive policy file. Has anyone noticed this?
- Mike

[Sri Addanki]

Hi Mark,
After reading some tutorial on RMI, i've decided to have the RMI security manager created on both client and server side like this:
System.setSecurityManager(new RMISecurityManager());
And i'm still getting the same error when i run the server.
access denied (java.io.FilePermission java.security.AccessControlException: access denied (java.io.FilePermission db.db write)
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.checkWrite(Unknown Source)
at java.io.File.canWrite(Unknown Source)
Do you think this error could be bcos of the db.db file?? (...and not bcos of RMI security manager) do you think db.db is inaccessible? If so what could be the reason, as such my scjd.policy file grants ALL permission.
Thanks,
Sri