I downloaded Netbeans 7.4 and Java 7 Update 51. I get the below error when I try to start Java DB or derby connection from Netbeans. This is on a windows 8 PC. I downloaded the version for windows xp 32 bit at work. It works fine. I am not sure what is missing.
Thu Jan 16 00:48:23 EST 2014 : Security manager installed using the Basic server security policy.
Thu Jan 16 00:48:24 EST 2014 : access denied ("java.net.SocketPermission" "localhost:1527" "listen,resolve")
java.security.AccessControlException: access denied ("java.net.SocketPermission" "localhost:1527" "listen,resolve")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372)
at java.security.AccessController.checkPermission(AccessController.java:559)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkListen(SecurityManager.java:1134)
at java.net.ServerSocket.bind(ServerSocket.java:375)
at java.net.ServerSocket.<init>(ServerSocket.java:237)
at javax.net.DefaultServerSocketFactory.createServerSocket(ServerSocketFactory.java:231)
at org.apache.derby.impl.drda.NetworkServerControlImpl.createServerSocket(Unknown Source)
at org.apache.derby.impl.drda.NetworkServerControlImpl.access$000(Unknown Source)
at org.apache.derby.impl.drda.NetworkServerControlImpl$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.derby.impl.drda.NetworkServerControlImpl.blockingStart(Unknown Source)
at org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(Unknown Source)
at org.apache.derby.drda.NetworkServerControl.main(Unknown Source)
This is what I did:
Find out exactly where the java home is by executing this instruction from NetBeans 7.4 :
System.out.println(System.getProperty("java.home"));
This is the output for my case:
C:\Program Files\Java\jdk1.7.0_51\jre
which is quite important for me, I was modifying another java.policy and took no effect and wasted me a couple of hours.
For reason of java.policy is an unix style file and read-only, I opened and edited it with notepad++ and executed as administrator (under the same java home):
C:\Program Files\Java\jdk1.7.0_51\jre\lib\security\java.policy
Add only these lines into the file after the first grant:
<pre>grant {
permission java.net.SocketPermission "localhost:1527", "listen";
};</pre>
Save the file, which is a little tricky for reason of the permission. But if you run notepad++ or any other edit program as administrator, you can solve the problem. Then try to connect the database from NetBeans, it works for me.
According to Java™ SE Development Kit 7, Update 51 Release Notes
Change in Default Socket Permissions
The default socket permissions assigned to all code including untrusted code have been changed in this release. Previously, all code was able to bind any socket type to any port number greater than or equal to 1024. It is still possible to bind sockets to the ephemeral port range on each system. The exact range of ephemeral ports varies from one operating system to another, but it is typically in the high range (such as from 49152 to 65535). The new restriction is that binding sockets outside of the ephemeral range now requires an explicit permission in the system security policy.
Most applications using client tcp sockets and a security manager will not see any problem, as these typically bind to ephemeral ports anyway. Applications using datagram sockets or server tcp sockets (and a security manager) may encounter security exceptions where none were seen before. If this occurs, users should review whether the port number being requested is expected, and if this is the case, a socket permission grant can be added to the local security policy, to resolve the issue.
This means that you have to explicity set the permissions for your application to be able to access the ports range between 1025 and 49151. You can therefore grant this permission by appending this line in the list of permissions granted:
Visit your Java Home Directory and access your policy file at $JAVA_HOME/jre/lib/security/java.policy and make the following changes.
grant{
//List of granted permissions
permission java.net.SocketPermission "localhost:1527", "listen";
}
See http://www.oracle.com/technetwork/java/javase/7u51-relnotes-2085002.html for the description of the "problem". Search other-libs/javadb
Depending on your requirement, what I did was go and modify the default security policy
cd $JAVA_HOME/jre/lib/security
Edit java.policy (make a backup first!)
Add the following
grant codeBase "file:${java.home}}/../db/lib/*" {
permission java.security.AllPermission;
};
Note that this is my requirement.
I'm granting every app who uses the u51 JRE the permission to start Derby.
EDIT
The alternative would be to use a less permissive set of permissions like:
grant codeBase "file:${java.home}}/../db/lib/*" {
permission java.net.SocketPermission "localhost:1527", "listen,resolve";
};
NetBeans, by default, uses the derby version installed with GlassFish. So my permissions look like this on the Mac. It will be similar on Windows, but the path will need to change.
grant codeBase "file:/Applications/NetBeans/glassfish-4.0/javadb/lib/*" {
permission java.net.SocketPermission "localhost:1527", "listen,resolve";
};
Because the upper measures didn't work I added the following permission to the end of the main permission section:
permission java.net.SocketPermission "localhost:1527", "listen,resolve";
You can also solve the problem on a per-user basis by granting the needed permission in a file called .java.policy in your home directory.
Works on both Unix and Windows systems as documented here: http://docs.oracle.com/javase/7/docs/technotes/guides/security/PolicyFiles.html
This might be useful if the system-wide policy file gets overwritten, for example when updating your JDK, or if you don't have permission to edit the system file.
This is what I have in my $HOME/.java.policy:
grant {
permission java.net.SocketPermission "localhost:1527", "listen";
};
I got a bit fed up with Oracle's approach to security lately. They seem to be trying to protect us from ourselves in ways that would be more appropriate to naive users than programmers. My view is that the code I put on my own machine should be able to do whatever it needs to. It's my fault if I put code there that does bad things. Clearly not a universally reliable perspective, but it's worked for me for about 35 years. On that basis, I add this to my /lib/security/java.policy file:
grant codeBase "file:/-" {
permission java.security.AllPermission;
};
note that the file:/- matches any file on the system, and the grant block says, in essence, "if the class is loaded from this file system, then trust it".
This was doing my head in for a bit until I stumbled across the following in the NetBeans wiki
JavaDB grant permissions
JavaDB grant permissions
How to grant permissions for Java DB / How to start Java DB
Related to issue #239962
JDK 7u51 comes with some security improvements which are causing
problems with starting Java DB on this Java version.
When you try to start DB from NetBeans you will probably get the
Exception:
java.security.AccessControlException: access denied
("java.net.SocketPermission" "localhost:1527" "listen,resolve")
The same exception you will get while starting using script /db/bin/startNetworkServer
Because there is no suitable way to fix it on the NetBeans side and
this should be fixed on the side of the Java DB.
There are several ways how to deal with this problem. I will mention
only the easiest way. You have to start DB manually from command line.
• Start Java DB with -noSecurityManager argument.
(JDK 7u51 location)/db/bin/startNetworkServer -noSecurityManager
Although it’s not exactly a solution it is usable as a quick workaround.
My solution to this was to reinstall jdk 1.7.45, uninstall netbeans and reinstall it selecting the outdated jdk. Don't know if there is a way to change sdk in NB without reinstalling it but it worked this way.
Well, one alternative is to change the port JavaDB listens to, to be now in the high range (such as from 49152 to 65535).
Go to Window->Services, then right click Java DB and in "Java DB Properties Dialog" goto to "Database Location", which in my system is "C:\Users\ahernandeza.netbeans-derby"
In that directory edit or create the file derby.properties, and add/edit the line:
derby.drda.portNumber=XXXX
Where XXXX is the new port, in my case i put 51527 and worked just fine.
EDIT
At fisrt glance it worked, the service started just fine, but when creating or starting a database in NB, i got the error Unable to connect. CAnnot establish a connection to jdbc:derby://localhost:1527/sample
Although i changed the pprt to 51527, it tries to connect to 1527
If linux, then
file=`find $(dirname $(readlink -f $(which java)))/.. -iname 'java.policy'`; grep 1527 $file || sudo sed -i '0,/"listen"/{s/"listen".*/\0\n\tpermission java.net.SocketPermission "localhost:1527", "listen";/}' $file
cat $file
it automatically finds your java and changes permissions
I found a quick solution to this problem -
Start your JavaDB from the command line\terminal like so:
<base folder>/db/bin/startNetworkServer -noSecurityManager
Then it runs fine without adding new permissions.
The problem is the Java 7u51, it have a bug that affect Derby and other programs and libraries, I suggest to install the Java 7u45
Related
I have a Java application which is running as non root mode.
My App will create a TFTP server (using apache commons tftp). TFTP server is bind to port 69(Default TFTP port). When running the app from IDE everything works fine since the IDE running as root. But if the app is run from other user i get the error
java.net.BindException: Permission denied
It is clear that for non root user i can not open the port. Is there a workaround for this issue?
For binding on Linux of ports less that 1024 you need to application to run a root. There is no way around this. If you need to do this you have you run as root. sudo might be the command to look into.
BTW - Running your IDE as root is not a very good idea.
To resolve this issue. You can use setuid() and setfid() system calls. So that you can temporarily elevate the permissions and then drop the permission back to user permissions.
In my Case, this problem happened in Solaris 11 OS. I added privileges to user to use the ports under 1024.
https://technicalsanctuary.wordpress.com/2014/06/03/allowing-a-user-to-use-ports-under-1024-on-solaris-11/
Is there a way to run Java VM (java.exe) on Windows Server 2008 and disable all network connections using a command line argument or a system variable?
You can do this by enabling default Java security manager. By default no security is enforced so you are allowed to do anything, but if security manager is enabled it will restrict network access, file access and lots of other things unless you specify otherwise in the security policy file.
To enable the default security manager pass this argument to JVM on start.
java -Djava.security.manager=default my.main.Class
By doing this any network access attempt from inside JVM will throw java.net.NetPermission.
This will also break things like file access, so if you need to allow it you will need to specify those in a special security policy file (-Djava.security.policy=path/to/policy.file). There should be plenty of examples of how to set it up, just search for "java permissions" to get you started.
I had the same task to test offline installer for our product. All said above is almost right, but creating .policy file is not easy for the first time. Here is what I did:
Crated generic policy file that has no permission to resolve host names (see code snippet below);
Added -Djava.security.manager -Djava.security.policy=pathto/policy.file in jvm parameters;
generic .policy file content:
grant {
permission java.io.FilePermission "<<ALL FILES>>", "read,write,execute,delete";
permission java.util.PropertyPermission "*", "read,write";
permission java.lang.RuntimePermission "*";
permission java.net.NetPermission "*";
permission java.lang.reflect.ReflectPermission "*";
};
If something tries to get content outside during the test, it fails with security exception.
Well, I haven't tried that but theoretically you could set the system properties for SOCKS proxy to a non-existent one and according to the documentation all TCP sockets will be tried through the SOCKS proxy - and fail.
Something like this:
java -DsocksProxyHost=127.0.0.1 SomeClass
I have a client-side security policy, with a statement that grants permissions. I want to be able to specify it to grant the set of permissions for an RMI server only. For example this works:
grant{
//my permissions
};
But I cant figure out how to link the set of permissions so that they apply to my codebase on the server. Actually anything, as long as its tied to the server would be fine. I have tried:
grant codeBase "file://hostname/-"{
//my permissions
};
With the hostname being the name or IP of the machine, both with and w/o the port number. But this does not work, neither does using http instead of file. If I understand what I read so far correctly the hyphen at the end should apply the permissions to anything located on the server. Anyone know what I need to do to get this to work?
Thanks.
Heres the codebase specified when running the server:
-Djava.rmi.server.codebase=file://home/me/PageServer/build/classes/ pageserver.LoginService pageserver.PlannerService
Where is the local JVM getting the code that should be granted permissions?
If it's downloading the code from an HTTP codebase on the server, you can use a URL starting with "http:".
If it's local code, you can use a URL starting with "file:" and ending with a local path.
Disclaimer: I've written security files for Jini, which is built atop RMI, and it's been a few years. Apologies for anything I've missed.
Use a JAR for the codebase, and specify exactly the HTTP URL in the .policy file that you specified in -Djava.rmi.server.codebase.
I'm having trouble getting RMI security policies working. I have a .policy file on both the server and client, each of which is running a SecurityManager.
When I try and run the client its failing. My policy file grants everything atm. Heres the content:
grant { permission java.security.AllPermission };
I have the file client.policy in the root directory of my JAR file (I tried running it with the policy file outside the jar too). Then I run the client with this:
java -jar PagePlanner.jar -Djava.security.policy=client.policy -Djava.rmi.codebase=http://192.168.0.88:2077/home/me/NetbeansProjects/PageServer/dist/PageServer.jar -Djava.security.debug=access
Specifying my policy file and the path to my code base. I'm not sure if either of these are correct. I also tried setting the debug switch as I read somewhere it should give me extra info about whats going wrong, but it does not seem to make a difference.Heres the output when I run the client:
Exception in thread "main" java.security.AccessControlException: access denied (java.awt.AWTPermission setWindowAlwaysOnTop)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
at java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.awt.Window.setAlwaysOnTop(Window.java:2038)
at gui.LoginForm.<init>(LoginForm.java:59)
at main.Main.main(Main.java:21)
From which point the client just hangs. Any ideas what I'm doing wrong here? The policy setup on the server-side is pretty much the same. I can post the details if that helps.
Cheers.
Run the client with -Djava.security.debug=access,failure. Most probably your .policy file isn't being found.
BTW you don't need to set the codebase at the client unless the client has its own implementations of abstract classes/interfaces and the server doesn't know about them. The codebase is normally only set at the server, so as to annotate classes that are downloaded to the client and the Registry.
I'm trying to do a Google App Engine project on OS X (latest and greatest). I'm using classes from javax.crypto, and I'm seeing an AccessControlException thrown when I try to initialize an instance of the Mac class. Here's the stack trace:
WARNING: Nested in java.lang.ExceptionInInitializerError:
java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.keychain)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
at java.security.AccessController.checkPermission(AccessController.java:427)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityManager.checkPermission(DevAppServerFactory.java:76)
at java.lang.SecurityManager.checkLink(SecurityManager.java:818)
at java.lang.Runtime.loadLibrary0(Runtime.java:816)
at java.lang.System.loadLibrary(System.java:993)
at com.apple.crypto.provider.HmacCore.<clinit>(HmacCore.java:26)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at java.lang.Class.newInstance0(Class.java:350)
at java.lang.Class.newInstance(Class.java:303)
at java.security.Provider$Service.newInstance(Provider.java:1130)
at javax.crypto.Mac.a(DashoA12275)
at javax.crypto.Mac.init(DashoA12275)
Any ideas on
1 - what went wrong and how fix it
2 - if it's not fixable (I know Apple has not been the best supporter of Java in recent years), what's an alternative approach?
Found a workround on google groups:
"To work around the local Mac SDK problem, you can pass
--jvm_flag=-D--enable_all_permissions=true to your dev_appserver. This will
cause the error to go away, but will unfortunately also disable most of the
security checking in your local environment. "
I have a more complete answer but without access to Apple's crypto provider source we'll never be fully sure what permissions are required on all their platforms. Here's what I was able to get working for snow leopard:
You'll need to grant whatever codebase needs the crypto the following permissions:
grand codebase "your/code/base" {
permission java.lang.RuntimePermission "loadLibrary.keychain";
permission java.io.FilePermission "/System/Library/Java/Extensions/-", "read";
permission java.io.FilePermission "/Library/Java/Extensions/-", "read";
permission java.io.FilePermission "/System/Library/Frameworks/JavaVM.framework/-", "read";
};
It appears there is some sort of search for the libkeychain.jnilib file that visits the first two locations before finding it in the Frameworks directory on OSX 10.6.2 for Java 1.6. Other versions of java and other versions of the OS may have additional or different search paths so the only way to solve it for each platform is to try, see the security permission exception, grant a file permission, then try again till it works. Fun.
One important caveat, if you try to load the crypto library into one classloader that is not part of this codebase then try to load it again into another classloader that is part of the codebase then you'll get a "native library already loaded in another classloader" exception.