Disabling the Sandbox
eric...@gmail.com
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
Roedy Green
or indirectly quoted someone who said :
>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.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
Andrew Thompson
>>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..
--
Andrew Thompson
http://www.athompson.info/andrew/
Message posted via http://www.javakb.com
eric...@gmail.com
> 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.
Thomas Hawtin
> Roedy Green wrote:
>> 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
eric...@gmail.com
> >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)
...
Andrew Thompson
>> 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?
(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.
Andrew Thompson
..
>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>
Andrew Thompson
..
>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. ;-)
--
Andrew Thompson
http://www.athompson.info/andrew/
Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200708/1
eric...@gmail.com
> 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
eric...@gmail.com
Thomas Hawtin
>
> * 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
Andrew Thompson
>> 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.
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
>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."
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.
>
>> 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.
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
>> >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?
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.
--
Andrew Thompson
http://www.athompson.info/andrew/
Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200708/1
Andrew Thompson
.
>> ...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.
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).
eric...@gmail.com
> 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