I found the cause for the Debian man man bug (in which you can't run man as
non-root user since 2.4.0-test6-pre1).
A strace of man shows us:
[...]
getuid() = 1000
geteuid() = 6
geteuid() = 6
setuid(1000) = 0
[...]
geteuid() = 1000
setuid(6) = 0
[...]
geteuid() = 6
setuid(1000) = -1 EPERM (Operation not permitted)
write(2, "man: ", 5) = 5
write(2, "can\'t set effective uid", 23) = 23
write(2, ": Operation not permitted", 25) = 25
write(2, "\n", 1) = 1
ioctl(0, SNDCTL_TMR_START, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
_exit(2) = ?
So, after a manual following of the sys_setuid code, I found the following
state transitions (with a little guessing -- I "guess" saved starts at 6):
(effective/real/saved)
6/1000/6 -> setuid(1000) -> 1000/1000/6
1000/1000/6 -> setuid (6) -> 6/6/6
6/6/6 -> setuid(1000) -> -EPERM
So, setuid is dropping too many perms. The culprit is the set_user function,
called from the uid == current->suid case in sys_setuid, which was introduced
in -- guess what -- test6-pre1.
} else if (uid == current->suid) {
if (set_user(uid) < 0)
return -EAGAIN;
} else
And in set_user
current->uid = new_ruid;
I can't fix it since I can't figure out what is the correct behavior for that
tangled web of functions. I also smell something fishy in set_user being called
only for the euid->suid case and not for the euid->ruid case. Someone who knows
better should take a look at that code.
I guess the Debian man-db is the only program in the face of the earth which
uses setuid instead of setreuid...
Speculations about the meaning of the uid being 6 are left as an exercise to
the confused reader.
-- Cesar Eduardo Barros cesarb@nitnet.com.br cesarb@dcc.ufrj.br- 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/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:20 EST