SuSE 10.1: Non-tls version of glibc?
We use Cadence here, and they compile parts of their software against a horribly old glibc without tls. So far, that has been no problem, since SuSE always provided a non-tls version of glibc, so the only thing to do was to set up the LD_LIBRARY_PATH in a way that Cadence loads this version. Now 10.1 drops the non-tls version, and certainly the non-tls glibc from 10.0 won't run on 10.1, either. Any ideas what to do (ok, issue a bug report to Cadence, but you get what you pay for, when you pay too much: arrogant assholes, driving Porsches and not caring about customers ;-). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
Bernd Paysan <bernd.paysan@gmx.de> writes:
I see only one option: Use a 10.0 chroot or xen instance on your 10.1 system. Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Tuesday 30 May 2006 17:59, Bernd Paysan wrote:
Now 10.1 drops the non-tls version, and certainly the non-tls glibc from 10.0 won't run on 10.1, either.
It should - assuming you also copy all depending libraries. -Andi
On Wednesday 31 May 2006 02:27, Andi Kleen wrote:
Unfortunately, /lib/ld-linux.so is one of the depending libraries (i.e. glibc-2.3.5 as of SuSE 10.0 won't work with the 10.1 /lib/ld-linux.so). Seems to be that Andreas' chroot solution seems to be necessary. However, ld-linux.so can run programs directly, so that might be an option to copy the old ld-linux.so into the Cadence lib directory and call the offending program using that ld-linux.so. But even using that I get the same error message, since the first process spawns further, which refer again to /lib/ld-linux.so.2: /cad/cds_ic_v5.0.33_usr3/tools/bin/clsbd: relocation error: /cad/cds_ic_v5.0.33_usr3/tools/lib/libc.so.6: symbol _dl_out_of_memory, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
On Wed, May 31, 2006 at 10:34:34AM +0200, Bernd Paysan wrote:
Then you most likely did something wrong. Since you did not tell us how exactly you called the linker I cannot tell you what. I once built a tool that automatically generates self-contained packages like http://db.informatik.uni-mannheim.de/downloads/natix/natix-2.1.0.tar.bz2 from a set of RPM packages and never saw any problems with these packages on any system. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."
On Friday 02 June 2006 16:59, Robert Schiele wrote:
With /<path-to-old-libraries>/ld-linux.so /<path-to-cadence>/icfb.exe. I have LD_LIBRARY_PATH set appropriate.
Do your programs exec() other programs with the same problems? Cadence does, and that's the problem. Apparently, there is no way to tell the Linux kernel that it should use another ld.so instead of /lib/ld-linux.so other than chroot - and chrooting just one specific X application is fairly difficult. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
On Friday 02 June 2006 17:34, Bernd Paysan wrote:
Hm, looked it up, the /lib/ld-linux.so path is hardcoded in the ELF program itself, in the .interp section. So a possible way to go is to patch this to /lib/ld-2.3.5.so (fit's nicely ;-). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
On Fri, Jun 02, 2006 at 05:34:24PM +0200, Bernd Paysan wrote:
The trick my tool does is to move away _all_ binaries to a different place and place a wrapper script like the natixshell script (from the example) to the old place. Thus an exec call does no longer hurt. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."
On Friday 02 June 2006 18:18, Robert Schiele wrote:
A possible different way would be to create a new name space using clone(CLONE_NEWNS) and overwrite all binaries/directories you want to be different with mount --bind in the new name space. There isn't a program included to do this but it should be relatively easy to write. -Andi
On Fri, Jun 02, 2006 at 11:39:40PM +0200, Andi Kleen wrote:
Sure but this cannot be run by an ordinary user then. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."
On Friday 02 June 2006 23:39, Andi Kleen wrote:
Sounds like ~10 lines of code, i.e. clone with the CLONE_NEWNS flag, and if you get a pid, wait for exit of all childs and exit(), otherwise mount() to "/lib" with the MS_BIND flag, set the user id, and exec() to the remainings of arg[] (or /bin/bash if empty). Thanks, that's the sort of help I wanted. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
On Mon, Jun 05, 2006 at 07:20:54PM +0200, Bernd Paysan wrote:
In principle yes. Actually this solution does provide some additional risks you should consider: A system that allows a normal user to execute applications with the SUID bit set together with user selected library replacements can trivially be compromised by this user. Thus unless you don't care about security at all you have to make sure that either only libraries can be installed that are approved by the sysadmin or that the user does no longer have the option to execute SUID or SGID binaries within the new namespace. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."
On Monday 05 June 2006 19:48, Robert Schiele wrote:
The library replacement is not user selected - it would be hard-coded into the wrapper. And it will be r/o for normal users.
Exactly. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
On Monday 05 June 2006 19:20, Bernd Paysan wrote:
And that's the code, compiled, setuid root. I post it for the record, so when someone googles for the problem, they'll also find the solution. This program has a discriminating license: You can freely use, modify, and distribute this program if you are licensee to the programs that have the assorted problems. You can't use, modify, and distribute this program if you are a licensor of broken programs, you have to fix them. Usage: (I call the program cdsshell) cdsshell without parameters starts bash in the changed environment cdsshell prog [args] starts the offending programm in the changed environment, <prog> is the full path to the program. --------------------------------------------------------------- /* old library wrapper */ #include <stdio.h> #include <sched.h> #include <sys/types.h> #include <sys/wait.h> #include <sys/mount.h> typedef struct { int argc; char ** argv; char ** env; } args; int clonelib(args * environ) { mount("/cad/cds-libs", "/lib", NULL, MS_BIND, NULL); /* or whatever path you choose for your compatibility libs, but make that hardcoded here! */ setuid(getuid()); /* drop privilege */ if(environ->argc == 1) { environ->argv[0] = "/bin/bash"; execve("/bin/bash", environ->argv, environ->env); } else { execve(environ->argv[1], environ->argv+1, environ->env); } } int main(int argc, char** argv, char ** env) { pid_t pid; int status; args environ = { argc, argv, env }; clone(clonelib, malloc(0x1008)+0x1000, CLONE_NEWNS | SIGCHLD, &environ); wait(&status); return status; } --------------------------------------------------------------- -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
Bernd Paysan <bernd.paysan@gmx.de> writes:
I see only one option: Use a 10.0 chroot or xen instance on your 10.1 system. Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Tuesday 30 May 2006 17:59, Bernd Paysan wrote:
Now 10.1 drops the non-tls version, and certainly the non-tls glibc from 10.0 won't run on 10.1, either.
It should - assuming you also copy all depending libraries. -Andi
On Wednesday 31 May 2006 02:27, Andi Kleen wrote:
Unfortunately, /lib/ld-linux.so is one of the depending libraries (i.e. glibc-2.3.5 as of SuSE 10.0 won't work with the 10.1 /lib/ld-linux.so). Seems to be that Andreas' chroot solution seems to be necessary. However, ld-linux.so can run programs directly, so that might be an option to copy the old ld-linux.so into the Cadence lib directory and call the offending program using that ld-linux.so. But even using that I get the same error message, since the first process spawns further, which refer again to /lib/ld-linux.so.2: /cad/cds_ic_v5.0.33_usr3/tools/bin/clsbd: relocation error: /cad/cds_ic_v5.0.33_usr3/tools/lib/libc.so.6: symbol _dl_out_of_memory, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
On Wed, May 31, 2006 at 10:34:34AM +0200, Bernd Paysan wrote:
Then you most likely did something wrong. Since you did not tell us how exactly you called the linker I cannot tell you what. I once built a tool that automatically generates self-contained packages like http://db.informatik.uni-mannheim.de/downloads/natix/natix-2.1.0.tar.bz2 from a set of RPM packages and never saw any problems with these packages on any system. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."
On Friday 02 June 2006 16:59, Robert Schiele wrote:
With /<path-to-old-libraries>/ld-linux.so /<path-to-cadence>/icfb.exe. I have LD_LIBRARY_PATH set appropriate.
Do your programs exec() other programs with the same problems? Cadence does, and that's the problem. Apparently, there is no way to tell the Linux kernel that it should use another ld.so instead of /lib/ld-linux.so other than chroot - and chrooting just one specific X application is fairly difficult. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
On Friday 02 June 2006 17:34, Bernd Paysan wrote:
Hm, looked it up, the /lib/ld-linux.so path is hardcoded in the ELF program itself, in the .interp section. So a possible way to go is to patch this to /lib/ld-2.3.5.so (fit's nicely ;-). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
On Fri, Jun 02, 2006 at 05:34:24PM +0200, Bernd Paysan wrote:
The trick my tool does is to move away _all_ binaries to a different place and place a wrapper script like the natixshell script (from the example) to the old place. Thus an exec call does no longer hurt. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."
On Friday 02 June 2006 18:18, Robert Schiele wrote:
A possible different way would be to create a new name space using clone(CLONE_NEWNS) and overwrite all binaries/directories you want to be different with mount --bind in the new name space. There isn't a program included to do this but it should be relatively easy to write. -Andi
On Fri, Jun 02, 2006 at 11:39:40PM +0200, Andi Kleen wrote:
Sure but this cannot be run by an ordinary user then. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."
On Friday 02 June 2006 23:39, Andi Kleen wrote:
Sounds like ~10 lines of code, i.e. clone with the CLONE_NEWNS flag, and if you get a pid, wait for exit of all childs and exit(), otherwise mount() to "/lib" with the MS_BIND flag, set the user id, and exec() to the remainings of arg[] (or /bin/bash if empty). Thanks, that's the sort of help I wanted. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
On Mon, Jun 05, 2006 at 07:20:54PM +0200, Bernd Paysan wrote:
In principle yes. Actually this solution does provide some additional risks you should consider: A system that allows a normal user to execute applications with the SUID bit set together with user selected library replacements can trivially be compromised by this user. Thus unless you don't care about security at all you have to make sure that either only libraries can be installed that are approved by the sysadmin or that the user does no longer have the option to execute SUID or SGID binaries within the new namespace. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."
participants (4)
-
Andi Kleen
-
Andreas Jaeger
-
Bernd Paysan
-
Robert Schiele