 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / August 2007Disabling the Sandbox
I'm trying to develop a java applet that operates outside the sandbox. I know I need to sign the applet for distribution, but for development purposes I'd like to be able to simply disable the sandbox, give my applet permission to do whatever it wants, even if that means temporarily disabling all security in my browser/VM/etc. Googling about I find references to a .java.profile file, but using the suggesting settings in that doesn't seem to work. I can't find options in Firefox, or IE to open up the sandbox. Can someone direct me to a solution, or a better forum to ask this question. I chose this one over java.security because it's active. Cheers, Eric >I know I need to sign the applet for distribution, but for development >purposes I'd like to be able to simply disable the sandbox, give my >applet permission to do whatever it wants, even if that means >temporarily disabling all security in my browser/VM/etc. I think someone said AppletViewer has no sandbox. You can make it a hybrid and run it as an application. See http://mindprod.com/jgloss/applet.html for how. code is included in the http://mindprod.com/products1.html#COMMON11 and http://mindprod.com/products1.html#COMMON13 Use an ANT script that does the signing. It takes only a second.  SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com >>I know I need to sign the applet for distribution, but for development >>purposes I'd like to be able to simply disable the sandbox, give my >>applet permission to do whatever it wants, even if that means >>temporarily disabling all security in my browser/VM/etc. > >I think someone said AppletViewer has no sandbox. Correct. (AV is also used by JWS to launch applets, and JWS imposes a sandbox, but that is not relevant to the type of use of the AV to which you refer). >You can make it a hybrid and run it as an application. Yes. This can be good for simple applets, but might require more work if the applet actively uses the parameter map, or opens other URL's etc. But, I prefer .. >Use an ANT script that does the signing. It takes only a second. ..the Ant solution for this day and age. After all, it can not only build and sign a project in a matter of moments, but you can also add an FTP task to upload the project (applet or JWS app.) when it is ready for deployment or update! To the OP. Any of the three methods outlined by Roedy is better than attempting to decipher those (damnable) policy files as they might interact with any real world browser. It might be possible to get it working on your dev. machine, but is probably not worth the bother. Since it makes sense to create an Ant script to build (sign) and deploy the applet, it makes sense to write it now, and use it during development. As an aside, even signed applets have 'issues' in IE on Vista - a new security model limits them to accessing files from specific directories. If it needs to be signed, or otherwise 'loosen' that restrictive sandbox for web deployed apps., I would tend to look to web start*. * Which, ironically, is also affected by the new Vista security model, but I /might/ have a fix for that problem.. SignatureAndrew Thompson http://www.athompson.info/andrew/ > As an aside, even signed applets have 'issues' in IE on > Vista - a new security model limits them to accessing > files from specific directories. If it needs to be signed, > or otherwise 'loosen' that restrictive sandbox for web > deployed apps., I would tend to look to web start*. *sigh* What about Flash? I don't really give a damn what language/tool I use, but it needs to be (1) cross platform, supporting at least Windows PC and Mac, (2) preferably browser-based so it can be seamlessly integrated with web content, (3) as transparent as possible to the user, automatically updating itself, etc. Simplicity (read: idiot- proofing) is the primary objective. Would Flash meet those requirements? Is this Applet restriction something Microsoft acknowledges as a problem on Vista -- something what will be eventually fixed -- or is it a permanent restriction? It seems pretty stupid that users are limited in what kinds of permissions they can willingly grant to web applications. >> As an aside, even signed applets have 'issues' in IE on >> Vista - a new security model limits them to accessing [quoted text clipped - 5 lines] > >What about Flash? (shrugs) ..dunno. Don't know Flash, don't have it installed. Last time I heard, it was going through some serious security issues, and I don't need the bother. What is it, in this *trusted* applet, that requires trust? Note that barring the 'seamless integration with web content' mentioned below, JWS would be a good fit for this, and could probably achieve what is needed in a sandboxed app. ... >...Simplicity (read: idiot-proofing) is the primary objective. No such thing. When you design something that is 'idiot-proof', they release a 'new and improved' idiot. Any user might not have *either* Flash or Java installed. Any user might not only not have it installed, but either be unwilling or *unable* (they don't control the hardware) to install it. Any user might have the right plug-in installed, but an insufficient version of it. It is *our* responsibility as developers to go to our best effort to either get the app. running, or to provide useful feedback to the user if that is not possible. That's why we get the 'big bucks'. ;-) >...Is this Applet restriction >something Microsoft acknowledges as a problem on Vista -- something >what will be eventually fixed -- or is it a permanent restriction? MS says it is Sun's problem, and there is a bug raised with Sun against it. I had not looked at the details closely, but many of the other Java developers involved seemed to see it as Sun's problem, though Sun was not showing any clear signs of rushing to put forward a fix. If you care that much, search the bug DB (always a chore) find the bug, and vote for it to be fixed. >...It >seems pretty stupid that users are limited in what kinds of >permissions they can willingly grant to web applications. Yeah, yeah.. preaching to the converted. ..You're new to this whole 'trusted apps. embedded in a web page' type project, aren't you? It might help for you to describe what it is your app. is intended to achieve (besides being embedded in a web page, involved with content and 'trust' I still have little idea what is the ultimate point) - the app. might not require as much trust as you expect. SignatureAndrew Thompson http://www.athompson.info/andrew/ > What is it, in this *trusted* applet, that requires trust? Access to any part of the user's file system that the user wants us to access. The user supplies the file name(s), by browsing or dragging and dropping them onto the applet. The applet then needs to read those files. The applet cannot be restricted to a subset of the file system: the files the users wants to supply us may come from anywhere on their machine. > Any user might not only not have it installed, but either be unwilling or > *unable* (they don't control the hardware) to install it. Any user might > have the right plug-in installed, but an insufficient version of it. For our purposes, if the user doesn't have control if their own machine, they won't be using our app. If they don't have the right version, *it's up to the plugin to be able to automatically update itself*. That's part of what I'm asking here. If the plugin cannot do that, I cannot use that plugin. > It is *our* responsibility as developers to go to our best effort to either > get the app. running, or to provide useful feedback to the user if that is > not possible. It is not my responsibility to ensure that Sun or Adobe has their act together. Look, the simplest option I can create for the *user* is to say "PC users click here" and "Mac users click here", and let each download a platform specific binary. In that case, *I* can make sure that each binary works on whatever version of Windows or MacOS the user may have. That's idiot-proof: it doesn't require the user to do *anything* special on their end to get the application to work. My desire for a cross-platform solution is to make *my* life easier, not the user's. I simply do not want to maintain two code bases. Now, if it turns out that the Java plugin is too stupid to keep itself updated, then that's Sun's problem, not mine (and a rather embarrassing one, this late in the game). I can't fix that, it just means I can't use Java. If Flash is too stupid to keep itself updated and/or there is no seamless, one-click solution to let the user download the latest version of the plugin and continue, than that's Adobe's problem, not mine. Again, I can't fix that, it just means I can't use Flash. >From what I've seen of Flash, it seems to very keep itself udpated transparently. If you don't have the required version, there's usually a 'click here to get the latest version' button, maybe enough click to give the appropriate permissions, and in minutes you're up to date. I don't know much more than that without investigating further. That level of user interaction is acceptable. What I *can't* have is something like "Sorry, you don't have the latest version of PLATFORM(tm), please visit PLATFORM AUTHOR's website and download the latest version of the PLATFORM RUNTIME(tm) and install it." It pretty much needs to be a one-click solution. > You're new to this whole 'trusted apps. embedded in a web page' type project, > aren't you? I have no idea if this is new or old, I just have something I want to do and am trying to figure out what tool to do it with. I really don't care who makes it or what language it is. No technology religion here at all. > erict...@gmail.com wrote: > >java.security.AccessControlException: access denied (java.io.FilePermission > >c:\path\file.ext read) > > 'That will fail on a Mac.' You did say this was meant to run on Win & Mac., > right? Why wouldn't it work? That path is not hardcoded (that's not even the actual path, I edited the error message to make the path generic, rather than reflecting my filesystem). That path comes from the user, via browsing or by drag and drop. I don't need to interact with the path contents at all, other than (in the case of Java) converting it to a String and showing it to the user, and passing it to a File object to access the file's contents. You mention JWS. Is that a one-click solution, or is the user going to be present with a "this application requires the latest version of the Java Runtime(tm)" type of dialog? Cheers, Eric Damn Google groups and their < 80 character display width. >> What is it, in this *trusted* applet, that requires trust? > [quoted text clipped - 3 lines] >dropping them >onto the applet. JWS. Drop the 'embedded in web page part' and this is all doable in JWS. >For our purposes, if the user doesn't have control if their own >machine, they >won't be using our app. OK - that removes a lot of problems. Web start launch can be made a lot smoother if the user can also be expected to have JS enabled in their browser. >...If they don't have the right version, *it's up >to the >plugin to be able to automatically update itself*. That's part of what >I'm >asking here. If the plugin cannot do that, I cannot use that plugin. Java does auto-update, and for Win. user's it is relatively transparent (as you describe below for Flash). One of Java Web Start's main advantages beyond ensuring the *application* is up to date, is to make sure the end-user has the minimum required version of Java, to run it in the first place. ... >> It is *our* responsibility as developers to go to our best effort to either >> get the app. running, or to provide useful feedback to the user if that is >> not possible. > >It is not my responsibility to ensure that Sun or Adobe has their act >together. I don't think you've put enough thought/research yet into the 'other side' of doing things from the internet. That is, the User Agent (read browser) that is being asked to interact with either Flash, or Java web start launched apps. (whether applet or application). This all comes to to the *serious* threat of getting viruses or other malware off binaries from internet sites. Sometimes a plug-in will attempt to do something that is 'vetoed' by the browser (or the OS, or any of a number of browser plug-ins (e.g. pop-up killers) or anti-virus software). The maker of the Plug-In only has so much control over the decisions of the browser manufacturers (and the rest of them) - most things are a matter of negotiation, but Sun (no idea about the makers of Flash) seems unwilling to take on browser manufacturers for the sake of applets. >Look, the simplest option I can create for the *user* is to say "PC >users click >here" and "Mac users click here", and let each download a platform >specific >binary. Is it? I have seen installers for Win. that curl up and die with no clear error message. But that is starting to sound like your app is not 'embedded' in a browser in any case. >..In that case, *I* can make sure that each binary works on >whatever >version of Windows or MacOS the user may have. Can you make it work on that ol' 486 of mine? I think it's running Win. 95. ;-) >>From what I've seen of Flash, it seems to very keep itself udpated >transparently. If you don't have the required version, there's usually [quoted text clipped - 11 lines] >PLATFORM >RUNTIME(tm) and install it." I think the current Java update situation is .. - tranpsarent for Windows - 'visit the site' for Mac. >...It pretty much needs to be a one-click >solution. [quoted text clipped - 7 lines] >makes it >or what language it is. No technology religion here at all. My point was not about competing tech., but having (any) trusted app. within a browser window, or 'coming at you' off the internet. >> erict...@gmail.com wrote: >> >java.security.AccessControlException: access denied (java.io.FilePermission [quoted text clipped - 4 lines] > >Why wouldn't it work? Note the quotes, they indicated, .. >...That path is not hardcoded ..if you presume that path to be hard coded. ( I hoped that would become clear from my later comments, but then I've hoped for a pony for a long time, and (checks) ..no sign of that yet, either ;) >..(that's not even the >actual >path, I edited the error message to make the path generic, rather than >reflecting my filesystem). That path comes from the user, via browsing >or by >drag and drop. I am relatively sure that D'n'D can be used in a sandboxed JWS App., but have not checked it. >..I don't need to interact with the path contents at all, >other >than (in the case of Java) converting it to a String and showing it to >the >user, and passing it to a File object to access the file's contents. The sandboxed JWS API does not allow you to get access to a standard java.io.File object, instead you work with a javax.jnlp.FileContents. It is similar, but more limited. <http://java.sun.com/javase/6/docs/jre/api/javaws/jnlp/javax/jnlp/FileContents.html >You mention JWS. Is that a one-click solution, or is the user going to >be >present with a "this application requires the latest version of the >Java >Runtime(tm)" type of dialog? If you app. requires Java 1.6, when the user has Java 1.4 (or 1.5, 1.3, 1.2 or 1.1) yes. If it is compatible with 1.4, any user with 1.4, 1.5, 1.6.. can use it straight away. Most of the file/access could be achieved in the JNLP API that existed when it was first released (during Java 1.2), but for GUI elements, 1.4 was a significant improvement. Java 1.5 added the ExtendedService to the JNLP API that allows the user to avoid a file open dialog when 'double click openning' a file with the app. Java 1.2 has already been shelved (long ago) and Java 1.4 should be going into EOL very soon. SignatureAndrew Thompson http://www.athompson.info/andrew/ > Is it? I have seen installers for Win. that curl > up and die with no clear error message. What in the name of God are you talking about? First of all, our app would not need an installer. Second, if you've seen installers fail (as more than a once-in-a-blue-moon anomaly), you need to stop buying your software from the bargain bin at the dollar store, and watch out for photocopied labels. > But that is starting to sound like your > app is not 'embedded' in a browser in any case. Yes, if I supply a link to a platform specific binary, the app will not be embedded in the browser. Thanks for pointing that out for the slower readers. > Can you make it work on that ol' 486 of mine? > I think it's running Win. 95. ;-) (1) Yes. If I distribute a Windows binary, it would be a pure Win32 app, runnable on anything post 3.1 pretty much. It would not require an installer. (2) That's a moot point, because if you were running a 486, you wouldn't be using our product anyway (or much of anything else remotely modern, for that matter). (3) You seem to be trying really hard to make a point, but damned if I can tell what it is. Are we a few posts away from "Mac > PC"? I'm feeling that creepy alternate-reality vibe setting in. > My point was not about competing tech., but having (any) trusted app. within > a browser window, or 'coming at you' off the internet. Applications can be digitally signed. The signature can be verified by an independent certification authority. My users can be assured that the application comes from me, so trust is not the primary issue. The problem is making sure the binary has a platform to run on when it arrives. > I am relatively sure that D'n'D can be used in a > sandboxed JWS App., but have not checked it. It can. Unfortunately this has nothing, whatsoever, to do with my issue, as explained in detail above. Anyway, for debugging purposes I'm just signing the applet now. There are several annoyances associated with that, but nobody seems how to turn the sandbox off locally for any platform and I'm tired of dicking around with it. I'm going to target Java 1.1, which I hope will have the broadest compatibility. I can write my own GUI widgets if needed. Maybe I can find a way to statically link in a VM and distribute one-click platform-specific binaries, while still letting me maintain a single Java code base for the core application. Thanks for the help, anyhoo. Cheers, Eric > >I think someone said AppletViewer has no sandbox. > > Correct. Hmmm... that's one of the first things I tried. I'm using the latest Java SDK, I type 'appletviwer myproject.html', yet I seem to get the exactly same sandbox as when I'm running in the browser. For instance, if I try to call File.isDirectory() I get: java.security.AccessControlException: access denied (java.io.FilePermission c:\path\file.ext read) 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.lang.SecurityManager.checkRead(SecurityManager.java:871) at java.io.File.isDirectory(File.java:752) at FileUploader.drop(FileUploader.java:68) at java.awt.dnd.DropTarget.drop(DropTarget.java:430) ... ... >java.security.AccessControlException: access denied >(java.io.FilePermission c:\path\file.ext read) 'That will fail on a Mac.' You did say this was meant to run on Win & Mac., right? So, is it that this file will eventually be on the same site as the applet? If so, the applet can be sandboxed. Check this post for details.. <http://groups.google.com/group/comp.lang.java.help/msg/2dab0b52bd3fc072> If the app. needs to access files on the client PC, JWS provides access to the local file system, even in a sandboxed app. Here is a demo, with build file. <http://www.physci.org/jws/#fs> SignatureAndrew Thompson http://www.athompson.info/andrew/ >> I think someone said AppletViewer has no sandbox. > > Correct. (AV is also used by JWS to launch applets, > and JWS imposes a sandbox, but that is not relevant > to the type of use of the AV to which you refer). The appletviewer sandbox works for me. Note, you can read (only) files from the path that the your classes are loaded from. That is necessary to, for instance, load resources and the class files themselves. Way back in 1.1, it classes on the classpath were treated as privileged (there was not the distinction of system and bot class loader back then). Applets often had a codebase of the current working directory, which was also used by the default classpath. IIRC, this meant they were loaded by the system class loader and given full privileges. This is not a problem for Java 2 (first released 1998). Applet support in the Java PlugIn and Java WebStart are extensions of the appletviewer code. There are some technical differences. I think the class loading is slightly different by default and PlugIn/WebStart, for instance, allows printing to go ahead after a dialog without any additional APIs. The source is of course available if you are interested. >> You can make it a hybrid and run it as an application. > > Yes. This can be good for simple applets, but might > require more work if the applet actively uses the > parameter map, or opens other URL's etc. I think it well worth doing anyway. >> Use an ANT script that does the signing. It takes only a second. > > .the Ant solution for this day and age. Or just a shell/batch file will do just as well. My preferred solution is to run in the sandbox, with the extra facilities Java WebStart gives you, or run as a normal application. Don't sign anything unless you know what you are doing. I am not aware of anyone who knows what they are doing. Tom Hawtin ... >Note, you can read (only) files from the path that the your classes are >loaded from. I suspect that is the problem with the OP's current attempts, but not knowing the path to the applet, or the codebase, it is hard to be sure. ... >Applet support in the Java PlugIn and Java WebStart are extensions of >the appletviewer code. There are some technical differences. I think the >class loading is slightly different by default ... It used to be, but there were a swathe of 'broken* web start app.' questions in the JWS forum over recent times when the classloaders for the applet plug-in and web start (for both applications and applets) was merged into a single entity. * Most of those questions were related to finding the location on disk where the classes were cached, and that was always a broken and fragile way to go about finding resources, even before Sun included an option for the end user to specify the cache location. Since 'getResource()' and plain URL's always worked seamlessly, I never bothered to look into it that carefully, beyond recommending to rework the app. to use them. >...and PlugIn/WebStart, for >instance, allows printing to go ahead after a dialog without any >additional APIs. Sockets, sure, but I thought the Print API was locked out, except by use of the PrintService** (had never bothered checking it though, and frustratingly - do not even have a printer to test my own JWS example!). ** <http://www.physci.org/jws/#prs> ... >My preferred solution is to run in the sandbox, with the extra >facilities Java WebStart gives you, ... I suspect that would suffice, for this app., and that it would therefore by the best choice, ..except for that tight browser integration. I mean - try and configure the launch parameters of a web start app., using JS. ;-) SignatureAndrew Thompson http://www.athompson.info/andrew/ > * Most of those questions were related to finding the > location on disk where the classes were cached, and > that was always a broken and fragile way to go about > finding resources, even before Sun included an option > for the end user to specify the cache location. The exact path name not predictable any more. There is a random element. IIRC, there were a number of IE/Netscape bugs that involved planting a script file in a guessable location on the victim machine, and then executing it as if it were from the local machine. > Sockets, sure, but I thought the Print API was locked out, > except by use of the PrintService** (had never bothered > checking it though, and frustratingly - do not even have > a printer to test my own JWS example!). I don't have a printer either (at least not in this (constituent) country). I guess I could use a print-to-file printer driver. Anyway, if you have the JDK source, deploy/src/plugin/share/classes/sun/plugin/security/ActivatorSecurityManager.java. The override of SecurityManager.checkPrintJobAccess first checks super, and if that fails opens a dialog. It confused me the first time I saw it as I was expecting a security exception but got a deadlock. Tom Hawtin .. >> ...I thought the Print API was locked out, >> except by use of the PrintService** (had never bothered [quoted text clipped - 3 lines] >I don't have a printer either (at least not in this (constituent) >country). I guess I could use a print-to-file printer driver. I'll have to look into that - I would love to check it myself. >Anyway, if you have the JDK source, >deploy/src/plugin/share/classes/sun/plugin/security/ActivatorSecurityManager.java. >The override of SecurityManager.checkPrintJobAccess first checks super, >and if that fails opens a dialog. It confused me the first time I saw it >as I was expecting a security exception but got a deadlock. ..'bummer' (assuming that delayed the project more than 30 seconds). SignatureAndrew Thompson http://www.athompson.info/andrew/ Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.