UNIX for Advanced & Expert Users

I have a simple sandbox program which runs a command as user "nobody" in a chroot jail. It sets resource limits with setrlimit, changes the user id with setuid, changes the root dir with chroot, and then calls exec to execute the command given as command line parameters. It is of course a setuid root program so that the call to chroot will work. FWIW, this is on a 64-bit machine running the latest Fedora.

It works fine when running as root; I can do things like:

Code:

   export FOO=bar
   export LD_LIBRARY_PATH=xxx
   export PATH=yyy:$PATH
   /usr/bin/printenv
   sandbox /myjail /usr/bin/printenv

(there is of course a copy of /usr/bin/printenv inside /myjail) and the environment outside the sandbox is exactly the same as inside.

Running it as a normal user, the environment outside the sandbox contains FOO, LD_LIBRARY_PATH, the modified PATH, and other things such as USER, HOME and NLSPATH. Inside the sandbox the environment is the same except that LD_LIBRARY_PATH and NLSPATH are missing!

I cannot for the life of me see why it should victimise these two variables and yet leave the rest of the environment. Can anyone help explain this puzzling behaviour?

TIA...

Setuid/setgid processes in Linux ignore LD_LIBRARY_PATH.

Thanks for your help. I don't see why it should do this, but... c'est la vie.
The real problem is that I'm trying to run Java inside the sandbox and it moans that it can't locate libjli.so. The only way I know around this is to set LD_LIBRARY_PATH. Can anyone suggest a workaround?

Because that would be an easy way for a casual user to compromise a system, i.e. execute malicious code as root.

---------- Post updated at 13:48 ---------- Previous update was at 13:36 ----------

Why do you need to set LD_LIBRARY_PATH for an internal library that should be found by default by the java run time ?
What says:

Code:

ldd /path-to/java

?

Code:

$ ldd /usr/java/jdk1.6.0_20/jre/bin/java
        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003ba8e00000)
	libjli.so => /usr/java/jdk1.6.0_20/jre/bin/../lib/amd64/jli/libjli.so (0x00002b1a5dcbc000)
	libdl.so.2 => /lib64/libdl.so.2 (0x0000003ba8a00000)
	libc.so.6 => /lib64/libc.so.6 (0x0000003ba8200000)
	/lib64/ld-linux-x86-64.so.2 (0x0000003ba7e00000)

However, there seems to be a problem with the design of the Java linker/loader, which uses LD_LIBRARY_PATH to set the java.library.path system property.
On Windows it uses PATH for this. And you can't redefine java.library.path using -D on the command line.

Googling elsewhere I found this comment: "For linux you set environment variable LD_LIBRARY_PATH, for windows you set PATH. IMHO the jdk should have added the value of java.library.path to the search path of the linker loader." What a mess!

Thanks for all your help...

The jli library is found so there should be no need to set the library path. Did you run the ldd command inside the chrooted environment ?

The same, but with libjli.so not found. Running java inside the jail gives me "java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory". I modified my sandbox to copy the value of LD_LIBRARY_SANDBOX to LD_LIBRARY_PATH, and then it works if LD_LIBRARY_SANDBOX is set. So dunno why, but it seems it is needed.