[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] docs/qemu-deprivilege: Revise and update with status and future plans
George Dunlap writes ("Re: [PATCH] docs/qemu-deprivilege: Revise and update with status and future plans"): > On 03/27/2018 02:33 PM, Ian Jackson wrote: > > Anyway IMO we should set RLIMIT_NPROC after fork and before execve. > > If this causes setuid to fail in qemu, qemu will crash. But this > > could only be the case if the new uid already has other processes, > > which it shouldn't do. (If it does, the new uid is probably > > contaminated by a previous domain with the same domid.) > > I was more worried about the limit not having the expected effect after > the setuid(). I think we can safely rule that out. > > I could find nothing in SuS explaining when process A may send signals > > to process B. So I resorted to the BSD manpages: > > > > https://www.unix.com/man-page/freebsd/2/kill/ > > > > For a process to have permission to send a signal to a process > > designated by pid, the user must be the super-user, or the real or > > saved user ID of the receiving process must match the real or > > effective user ID of the sending process. > > The text of both the FreeBSD and Linux man pages looks to be copied > verbatim from [1]. > > [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/kill.html I don't know how I missed that. It's the 2nd paragraph! > > `pet' could be a uid associated with a reserved domid, eg dom0. > > Right -- it looks like that could work. I hadn't initially noticed the > {RUID, SUID} => {RUID, EUID} distinction. > > It's kind of hard to believe this is so difficult to pull off. Yes! > Should we post this to that forum, for the benefit of other people who > end up finding the same discussion? :-) Tempting. Let's wait until we see if it works, first ... Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |