Bug#413326: killing setuid programs (user-launched xinit can't kill X server at end of session)
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 <firstname.lastname@example.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