Messages in this thread | | | Date | Wed, 16 Sep 1998 19:45:55 +0200 | From | Roger Espel Llima <> | Subject | fixing the rwx--x--x problem |
| |
pacman wrote: > Well, I just looked it over, and all it does to detect setuid is compare > getuid() against geteuid() (And likewise for gid). That does serve to > illustrate a flaw in my theory. set-id doesn't just disable LD_* in the > immediately exec'ed program, it disables it in all further exec's within the > same process and its children. Applying that same rule to --x exec's would be > overkill. [...] > > Anyway, back to my point. Since there doesn't seem to be an easy way for > ld-linux.so to know whether the main executable is readable or not, the only > safe alternative right now seems to be, if you're going to use --x programs, > link them statically (and for the sake of dlopen, unset LD_* first thing in > main().) This is a very un-graceful workaround. If /proc/self/exe behaved as > I had expected it to, it would all be so simple...
how about using the OpenBSD approach.. a flag in the task struct that remembers if the program is "suid", and having ld.so check that instead of checking various uid's, via a system call (issetugid() or something like that).
then various libc functions can use that to decide whether they should honor some environment variables that change the way some functions behave.
to fix the rwx--x--x problem, issetugid() could be made to return various flags, like
#define ISSETUID 1 #define ISSETGID 2 #define EXECNOREAD 4
ld.so could treat non-readable executables like suid ones, disallowing LD_*.
and on exec the kernel could mask out the EXECNOREAD flag, so that the rwx--x--x restrictions don't apply after an exec.
-- Roger Espel Llima, espel@llaic.u-clermont1.fr http://www.eleves.ens.fr:8080/home/espel/index.html
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |