accessdenied java error after uploading with file manager

Submitted by neuron on Fri, 01/28/2011 - 06:19

I get this error after "upload and unpack" of a file: Failed to list /home/torv/public_html : java.security.AccessControlException : access denied (java.net.SocketPermission 123.123.123.123:10000 connect,resolve)

The file is uploaded fine, and refreshing. The ip adress is the right adress for the server (it's a vps, which might be the problem).

I'm completely stumped on how to debug this.

Status: 
Closed (fixed)

Comments

Submitted by andreychek on Fri, 01/28/2011 - 09:10

Howdy -- what browser and browser version are you using to access Virtualmin? Does it by chance work in a different browser?

Submitted by JamieCameron on Fri, 01/28/2011 - 12:55

Also, are you connecting to your Virtualmin system via a proxy, or is it behind a NAT gateway?

Submitted by neuron on Mon, 01/31/2011 - 02:01

It's from a NAT gateway, I've had no problem with other virtualmin installs. So I'm guessing it's some way the VPS is set up.

We've tried in a few different browsers now. Firefox : Reports the error in the original report. Opera : Works, no errors. But while the popup window is open the entire background is black. Chrome : The guy I had testing it couldn't figure out how to allow the popup window coming up.

Submitted by JamieCameron on Mon, 01/31/2011 - 12:26

There are unfortunately some issues with Java and NAT that can cause this - it gets confused about what is the real IP of the system, and throws that exception because Java thinks the applet is connecting to an invalid IP :-(

Submitted by neuron on Tue, 02/01/2011 - 07:02

What can we do about it? I doubt we're the only ones running virtualmin on a VPS setup.

This is the ifconfig output:

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:68073 errors:0 dropped:0 overruns:0 frame:0 TX packets:68073 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:5440360 (5.4 MB) TX bytes:5440360 (5.4 MB)

venet0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:127.0.0.1 P-t-P:127.0.0.1 Bcast:0.0.0.0 Mask:255.255.255.255 UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1 RX packets:26316022 errors:0 dropped:0 overruns:0 frame:0 TX packets:35598773 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:15750364907 (15.7 GB) TX bytes:42694082721 (42.6 GB)

venet0:0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:123.123.123.123 P-t-P:123.123.123.123 Bcast:0.0.0.0 Mask:255.255.255.255 UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1

Ip adress masked to 123.123.123 for security.

Submitted by JamieCameron on Tue, 02/01/2011 - 13:40

It isn't so much that you are using a VPS that triggers this, but rather that your Virtualmin system is being a NAT gateway. I generally recommend avoiding that for web hosting, as it adds additional complexity due to mismatches between the externally visible IP, and the IP the system thinks it has.

Submitted by neuron on Wed, 02/02/2011 - 01:39

Yes but this is a java issue not a general hosting issue.

Short of building a new file manager, is there anything we can do about this? The file manager is the only big problem I have with virtualmin, but the popup based java solution is giving me headaches with a lot of clients on different browsers and setups.

Submitted by JamieCameron on Wed, 02/02/2011 - 23:55

If you like, I could login to your system myself to debug this further .. if that is possible, you can send me login details at jcameron@virtualmin.com . Even a domain owner login with access to the file manager would be useful.

Submitted by neuron on Thu, 02/03/2011 - 02:33

Excelent, that'd be great! I'll mail you a login. :)

Submitted by JamieCameron on Thu, 02/03/2011 - 14:58

Thanks for the login ..

I just connected to your system, using Chrome on a Mac and the file manager loaded just fine!

Which browser and OS are you using there?

Submitted by neuron on Fri, 02/04/2011 - 01:39

The file manager loads, but the file upload is broken.

On firefox it reports the error in the first post. On chrome the popup blocker hides the popup, and won't easily let our clients access it. On opera the popup works, and the entire back window goes black while its uploading.

My testers are on windows systems. Java is updated to the latest version, and so are most browsers (they are atleast very recent versions).

Submitted by JamieCameron on Sun, 02/06/2011 - 22:17

Ok, I figured out the cause now .. when you upload a zip file, the javascript code in the browser calls back to the file manager java code to refresh the directory listing in the UI. However, there appears to be some java security policy that prevents java functions called in this way from making network connections .. which is what causes that error window.

Fortunately it is mostly cosmetic, as the file does actually get uploaded OK - all you need to do is click Refresh to see the new directory listing. In the next webmin release, I will handle this case and suppress the error message.

Submitted by JamieCameron on Sun, 02/06/2011 - 22:31

Ok, I figured out the cause now .. when you upload a zip file, the javascript code in the browser calls back to the file manager java code to refresh the directory listing in the UI. However, there appears to be some java security policy that prevents java functions called in this way from making network connections .. which is what causes that error window.

Fortunately it is mostly cosmetic, as the file does actually get uploaded OK - all you need to do is click Refresh to see the new directory listing. In the next webmin release, I will handle this case and suppress the error message.

Submitted by Issues on Mon, 02/21/2011 - 02:21

Automatically closed -- issue fixed for 2 weeks with no activity.