This is still an issue, reported again by a user. Samuel Thibault, le Sun 04 Mar 2007 14:38:31 +0100, a écrit : > The following issue is still not resolved, resulting to X session not > properly killing the X server at its end of its life. > > Samuel Thibault, le Tue 29 Aug 2006 21:10:14 +0200, a écrit : > > Thomas Bushnell BSG, le Tue 29 Aug 2006 11:58:43 -0700, a écrit : > > > Samuel Thibault <samuel.thiba...@ens-lyon.org> writes: > > > > > > > Roland McGrath, le Mon 28 Aug 2006 17:34:24 -0700, a écrit : > > > >> It sounds like you are describing the intended behavior. > > > >> You can't send a signal to a setuid program with kill. > > > > > > > > For a process to have permission to send a signal to a process > > > > designated > > > > by pid, unless the sending process has appropriate privileges, the > > > > real or > > > > effective user ID of the sending process shall match the real or saved > > > > set-user-ID of the receiving process. > > > > > > > > And setuid programs keep the real user ID set to Joe user's, so that Joe > > > > user can kill the program he launches. > > > > > > This is not quite correct. > > > > > > Most setuid programs do *not* keep the real user ID alone; instead, > > > the explicitly change it to match the effective user ID. This is > > > important. > > > > Setuid programs themselves might, yes. But the system mustn't change > > it itself (Hurd's proc correctly doesn't). Because some programs other > > than passwd (an X server for instance) need to be killable by the very > > user that started it (via xinit). > > > > > If the "passwd" program could be interrupted at will be > > > its caller, for example, then it might leave an incompletely written > > > and locked password file around. > > > > Agreed. But posix says (and some setuid programs rely on this) that by > > default, a setuid program can be killed by the user who launched it. > > You didn't comment any more on this, so I guess you agree on this? > > Now, the original question is still: > > ``There's an issue with Joe user being able to kill setuid programs that > he launches: on the sending side, glibc does: > > err = HURD_MSGPORT_RPC (__proc_getmsgport (proc, pid, &msgport), > (taskerr = __proc_pid2task (proc, pid, > &refport)) ? > __proc_getsidport (proc, &refport) : 0, 1, > kill_port (msgport, refport)); > } > > I.e. asks proc for the task port, and if that fails, asks proc for the > session port, then it sends the signal. > > It happens that since the target got setuid'ed, the proc server had set > it owned by root, and hence pid2task fails. I don't know exactly what > having a port on a task means, but I guess that's on purpose that even > if the real uid is Joe user, Joe user shouldn't have a task port on the > setuid-ed program. > > As a result only proc_getsidport() works. > > And on the receiving side, the ref port needs to be the task port for > letting any signal come in...'' > > So how should this be fixed for letting Joe kill his X server at the end > of his session? Shouldn't Joe be allowed to have a task port on the > setuid-ed program? Or do we need to implement another port which would > just let him do the few operations he can do as the real owner of the X > server?
