problem with setuid bit

problem with setuid bit

Post by hember » Wed, 22 Dec 1999 04:00:00



we have an executable installed with setuid bit (rwsr-sr-x) on solaris
2.6
when we use it, it can't find dynamic libraries.
the only work around we found, is to create a link in /usr/lib for each
librarie on each computer.
it involve we use only one release of each librarie by computer.
has some body an other solution?
 
 
 

problem with setuid bit

Post by Martin Pau » Wed, 22 Dec 1999 04:00:00



> we have an executable installed with setuid bit (rwsr-sr-x) on solaris
> 2.6
> when we use it, it can't find dynamic libraries.
> the only work around we found, is to create a link in /usr/lib for each
> librarie on each computer.
> it involve we use only one release of each librarie by computer.
> has some body an other solution?

it's a security feature - see `man ld.so.1` for details.

You can work around this if you specify the correct run path during
the linking stage (IF you compile the binary yourself). It's the
-R flag, and you should use this instead of LD_LIBRARY_PATH anyway.

hth, mp.
--
                         Martin Paul | Systems Administrator

                and Parallel Systems | Tel: 01-3105608-84
Liechtensteinstrasse 22, A-1090 Wien | Fax: 01-3105608-88

 
 
 

problem with setuid bit

Post by Kenny McCorma » Wed, 22 Dec 1999 04:00:00




...

Quote:>it's a security feature - see `man ld.so.1` for details.

>You can work around this if you specify the correct run path during
>the linking stage (IF you compile the binary yourself). It's the
>-R flag, and you should use this instead of LD_LIBRARY_PATH anyway.

Another work around that is easier than re-linking - especially if you don't
have source handy to re-compile/re-link is this (assuming that
LD_LIBRARY_ATH is indeed the problem - this has not been verified by the
original poster):

        1) Rename the binary to some-other-name and chmod it back to 755.
        2) Write a setuid wrapper, like this:

                /* Untested and not all there, but you get the idea... */
                /* Read the man pages for the various functions, etc */
                main(argc,argv)
                char **argv;
                {
                putenv("LD_LIBRARY_PATH=<whatever>");
                execl("some-other-name" <whatever>);
                }

        3) Compile this as "your-program-name" and make *it* setuid.

 
 
 

problem with setuid bit

Post by Casper H.S. Dik - Network Security Engine » Wed, 22 Dec 1999 04:00:00


[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]




>...
>>it's a security feature - see `man ld.so.1` for details.

>>You can work around this if you specify the correct run path during
>>the linking stage (IF you compile the binary yourself). It's the
>>-R flag, and you should use this instead of LD_LIBRARY_PATH anyway.
>Another work around that is easier than re-linking - especially if you don't
>have source handy to re-compile/re-link is this (assuming that
>LD_LIBRARY_ATH is indeed the problem - this has not been verified by the
>original poster):
>    1) Rename the binary to some-other-name and chmod it back to 755.
>    2) Write a setuid wrapper, like this:
>            /* Untested and not all there, but you get the idea... */
>            /* Read the man pages for the various functions, etc */
>            main(argc,argv)
>            char **argv;
>            {
>            putenv("LD_LIBRARY_PATH=<whatever>");
>            execl("some-other-name" <whatever>);
>            }
>    3) Compile this as "your-program-name" and make *it* setuid.

And this will not work either as the runtime linker doesn't care
about the set-uidness of the program but only whether euid == uid.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

problem with setuid bit

Post by Kenny McCorma » Wed, 22 Dec 1999 04:00:00




...

Quote:>And this will not work either as the runtime linker doesn't care
>about the set-uidness of the program but only whether euid == uid.

OK, since you have the source, I will defer to you.  But I'm pretty
sure I've successfully done something similar to this under Linux.  I
know that Linux *does* clear LD_LIBRARY_PATH from the environment when
you "pass through" a setuid program (i.e., if there is a setuid program in
your execution chain).

So, it seems that Solaris's implementation of the idea is more secure than
Linux's.

 
 
 

1. setuid bit problems w/ ext2 fs

We're stumped!

The worst part is we're pretty sure it's some stupid switch somewhere
or another that's causing it & the solution will be embarrasing, but
here goes:

We've got a Linux 1.2.13 kernel running on a Pentium with some IDE
hard disks and some SCSI tape devices.  All the file systems are ext2.
The distribution is Slackware in which the original kernel was 1.2.8.

We can't seem to make setuid/setgid bits work!!  We've tried all kinds
of ext2 mount options (including including the setuid ones and the
default ones) to no avail:  no setuid/setgrp files work!  It's as if
the mechanism just weren't there (e.g. if user X (root or otherwise)
setuid's a file and user Y runs it, the EUID is that of Y's).

Embarass us, please!! :)

Dave Parker
Sr. Systems Analyst
Frontier Information Technologies
Phone: (414)592-6616

2. ftpd and shadow: too many links error

3. SetUID bit Problem !

4. Can I run it on a 286?

5. Need help with setuid() problems on 386/ix with setuid root program.

6. CHICAGO UNIX SYSTEMS ADMINISTRATOR POSITION

7. tcsh script with setuid bit on Sol2.6/2.7

8. problem with CD and SCO?

9. setuid root bit doesn't!

10. sticky bit & setuid???

11. setuid bit on shell scripts - works? or not?

12. SGI IRIX 6.5: setuid root bit is off

13. Does Linux honor the setuid bit on shell scripts?