-
Enhancement
-
Resolution: Unresolved
-
P4
-
None
-
1.3.0
-
Cause Known
-
sparc
-
solaris_2.6
I'm entering this rfe for a friend. See comments.
> The ability to change process permissions from one user/group to
> another. This is important for a web server because to attach to port
> 80 on Unix you have to be root, but no one wants to run their web server
> as root, so web servers start out as root then setuid to a less-priv'd
> user. Java Web Server has to use C code to accomplish this, which is
> sad. Perhaps setUserId()/setGroupId() could be methods of
> java.lang.Runtime. The trick, and why it probably hasn't been done
> before, is that there's no easy portable way to specify the user/group
> that you want to be set to. Bigger problems have been solved though.
> You could have the method take a string, and for portability you could
> have a PRIVILEGED_USER constant that was "root" on Unix, "Administrator"
> on NT, and what not. The method could throw an exception if the setuid
> didn't work such as on an OS without users. I figure, heck, if we can
> manipulate File objects even though the machine may not support files,
> we may as well manipulate users even though the machine may not have
> users. Since all the popular OS's do afterall.
> The ability to change process permissions from one user/group to
> another. This is important for a web server because to attach to port
> 80 on Unix you have to be root, but no one wants to run their web server
> as root, so web servers start out as root then setuid to a less-priv'd
> user. Java Web Server has to use C code to accomplish this, which is
> sad. Perhaps setUserId()/setGroupId() could be methods of
> java.lang.Runtime. The trick, and why it probably hasn't been done
> before, is that there's no easy portable way to specify the user/group
> that you want to be set to. Bigger problems have been solved though.
> You could have the method take a string, and for portability you could
> have a PRIVILEGED_USER constant that was "root" on Unix, "Administrator"
> on NT, and what not. The method could throw an exception if the setuid
> didn't work such as on an OS without users. I figure, heck, if we can
> manipulate File objects even though the machine may not support files,
> we may as well manipulate users even though the machine may not have
> users. Since all the popular OS's do afterall.
- relates to
-
JDK-4931106 Native setuid() call causes JVM hang
- Closed