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.
So I thought, how about looking at the permissions on /proc/self/exe, that
might work. And the behavior I discovered was... interesting:
$ cp /bin/ls /tmp/ls
$ chmod 100 /tmp/ls
$ strace /tmp/ls -lL /proc/self/exe
[...]
stat("/proc/self/exe", 0xbffff87c) = -1 EACCES (Permission denied)
Why is that? Seems to me /proc/self/exe is a symlink to a file with permission
100. stat()'ing it shouldn't be a problem. permission to stat() a file is
supposed to be related to the x permission on the directory that contains it.
And check this out:
lstat("/proc/self/exe", {st_mode=S_IFLNK|0700, st_size=64, ...}) = 0
readlink("/proc/self/exe", 0xbffff4b0, 1025) = -1 EACCES (Permission denied)
readlink returning EACCES on a file where lstat succeeded? Bizarre...
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...
-
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/