[EMAIL PROTECTED] wrote:
>
> >
> > these should ideally only be allowed to:
> >
> > - read files under certain canonical path
> > - write files under another canon. path
> > [...]
> That won't work...imagine this case...someone could write a shell script
> that got executed by the Java code...now you are just locking down more
> than the file read/write classes/methods...
>
> You are opening up a can of worms with what you are trying to do. Your
> best bet is to have each user run their own VM in their own zone. That
> way, they can only destroy files they have unix privs to destroy.
>
> -jon
Jon, if you read again my post, what I want to do is to allow just a few
things, and not the reverse (just restricting read/write from/to files)
as you imply.
As I mentioned, this means at least allowing read/write files at the
appropriate places, and also allow binding to ports over 1024. Other
things, like introspection (to some extent) are candidates to my list.
Therefore, your servlet won't be able to execute your script if you
don't allow this explicitly in your custom securitymanager.
Concerning the use of operating system security, of course I'm going to
execute the JVM under a non-privileged account. But this is not the
equivalent of a chrooted environment. Lots of files are world-readable
on a typical UNIX installation (not to talk about NT, where I haven't
seen yet an installation with a careful permission administration).
These world readable files are for the system users, which you are
trusting to some extent after all. For fully _untrusted_ users, there
are the typical chroot setups, and that's what I want. There are more
tools you can use on certain systems, but for example you can't do
Capabilities on many UNIX systems yet (and it's buggy on a few others).
So I think it's a good (or less worse if you want) idea to use a Java
security manager even when it is a mess (agreed). Without this, no ISP
in the World is going to use JServ to provide servlet hosting, IMO.
Carlos
--
----------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
