Date: Tue, 25 Jun 2002 18:04:08 -0700 (PDT) From: Dan Hulme <dan_256@yahoo.com> To: znerd@FreeBSD.ORG, freebsd-java@freebsd.org Subject: Jboss3ctl update (I think I know the problem) Message-ID: <20020626010408.70596.qmail@web13403.mail.yahoo.com>
next in thread | raw e-mail | index | archive | help
Problem:
The problem lies in the .java_wrapper script. This script sets up a few important variables in
the environment that are needed to run the java binary, and then procedes to execute it. This
works fine most of the time.
See "man sh":
-p privileged
Turn on privileged mode. This mode is enabled on startup if
either the effective user or group id is not equal to the real
user or group id. Turning this mode off sets the effective user
and group ids to the real user and group ids. When this mode is
enabled for interactive shells, the file /etc/suid_profile is
sourced instead of ~/.profile after /etc/profile is sourced, and
the contents of the ENV variable are ignored.
According to this, the environment will be ignored if the effective user is not the real user.
Since this is precisely what will happen if .java_wrapper is invoked by jboss3ctl, it stands to
reason that the necessary vars that are setup in .java_wrapper will be ignored, giving the shared
library error that I get frequently:
/usr/libexec/ld-elf.so.1: Shared object "libhpi.so" not found
One of the vars that gets set is LD_LIBRARY_PATH. Note the following from "man ldconfig":
Security
Special care must be taken when loading shared libraries into the address
space of set-user-Id programs. Whenever such a program is run, the
dynamic linker will only load shared libraries from the hints file. In
particular, the LD_LIBRARY_PATH is not used to search for libraries.
Thus, the role of ldconfig is dual. In addition to building a set of
hints for quick lookup, it also serves to specify the trusted collection
of directories from which shared objects can be safely loaded.
According to this, this var will be ignored in this case, because jboss3ctl is surely a
"set-user-Id" program. So, the .java_wrapper will fail if called by a suid program like
jboss3ctl. You could get around this by adding these java libs to the safe paths, but this is
probably not worth it.
Conclusion:
.java_wrapper (apparently sun's current solution) will not work when invoked by a suid program.
So far, I have encountered two such programs: tomcat, and jboss (essentially the same design).
There is a good reason for not letting suid programs call shared libraries depending on the ENV
variables, so I understand why this happens.
This explains why the bootup script for jboss and tomcat is forced to call su -m www -c
"jboss3ctl" to get the env to work: this avoids a change to user when the executable runs. If
this worked normally, there would be no reason to force a change with su, because the executable
should already do that.
Solution:
I'm not sure of a good one, because the idea is to allow multiple users to be able to
start/stop/restart the server just by being a member of the group www. That said, there are many
ways to get minimal functionality:
1). Run as root, using su, like the startup script
2). Use java -jar run.jar
3). Create an account to run the daemon, and allow logins to that account. Give permissions to
only that account to run it.
4). Fix java so it doesn't need a library path (static).
Please suggest further solutions if you have any ideas.
Errors:
I may have misinterpreted what I found, and my problem may be singular. I would love to find out
that I am wrong, so if I am, please correct me and explain how to fix my problem.
-Dan
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-java" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020626010408.70596.qmail>