Re: killing setuid programs
retitle 413326 user-launched xinit can't kill X server at end of session thanks Hi, 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 [EMAIL PROTECTED] 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? Samuel ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Google Summer of Code 2007
[Please follow up on bug-hurd@gnu.org only; no need to be subscribed.] Hello! Like they did last year, Google is again hosting a Summer of Code program in 2007. See http://code.google.com/soc/. The GNU project is again going to apply for being a mentoring organization and has asked the various GNU subproject to already begin collecting ideas about projects being worth attending there. See http://gnu.org/software/soc-projects/guidelines.html Do we, the GNU Hurd project, want to participate in 2007? A timeline is available at http://code.google.com/support/bin/answer.py?answer=60325 and condeses to mentoring organizations having to apply this week and students having to apply in two weeks. Students will begin working on (and mentors begin mentoring) their projects at the end of May and finish towards the end of August. I can already now estimate that I won't be able to invest a lot of time into mentoring during that period (due to university study work). I nevertheless offer to again be a mentor this year. What are other potential mentor's comments? Suitable tasks would again be made up from the ones already registered at http://savannah.gnu.org/task/?group=hurd and from the ones you are going to send in now. Regards, Thomas signature.asc Description: Digital signature ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
[task #6584] Improve Xen support
URL: http://savannah.gnu.org/task/?6584 Summary: Improve Xen support Project: The GNU Hurd Submitted by: sthibaul Submitted on: lundi 05.03.2007 à 02:03 Category: None Should Start On: lundi 05.03.2007 à 00:00 Should be Finished on: lundi 05.03.2007 à 00:00 Priority: 1 - Later Status: None Privacy: Public Percent Complete: 0% Assigned to: None Open/Closed: Open Discussion Lock: Any Planned Release: None Effort: 0.00 Wiki-like text discussion box: ___ Details: - Batch hypercalls where possible - remaining TODOs - Use elfnote.h - PAE Support - I/O Support - HVM Support? (I don't know if anything is needed for domU) - Implement debug registers (but GNU Mach itself doesn't support it yet for userland) - Net/Block hotplug - Memory balloon driver - framebuffer+keyboard+mouse support - PCI support - native X support - dom0 support ? :) ___ Reply to this item at: http://savannah.gnu.org/task/?6584 ___ Message posté via/par Savannah http://savannah.gnu.org/ ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Glibc-2.5 with TLS cont'd
Hey folks,
Thanks to Samuel I got past my errno problems but now I am getting this
error:
/devel3/bdefreese/glibc-2.5/glibc-2.5/build/libc_pic.os: In function
`__pause_nocancel':
../sysdeps/posix/pause.c:55: undefined reference to `sigsuspend_not_cancel'
collect2: ld returned 1 exit status
make[1]: *** [/devel3/bdefreese/glibc-2.5/glibc-2.5/build/libc.so] Error 1
make[1]: Leaving directory `/devel3/bdefreese/glibc-2.5/glibc-2.5'
make: *** [all] Error 2
This is the offending section from pause.c:
#ifndef NO_CANCELLATION
# include not-cancel.h
int
__pause_nocancel (void)
{
sigset_t set;
__sigemptyset (set);
__sigprocmask (SIG_BLOCK, NULL, set);
return sigsuspend_not_cancel (set);
}
#endif
As far as I can tell this stuff is coming from nptl. Do we want to head
down that road or should I be trying to work around this? I assume that
nptl would be A LOT more work?
Thanks,
Barry deFreese
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
