From mboxrd@z Thu Jan 1 00:00:00 1970 From: random832@fastmail.com (Random832) Date: Fri, 12 May 2017 20:48:35 -0400 Subject: [TUHS] The evolution of Unix facilities and architecture In-Reply-To: References: <20170512233012.7B9DB18C099@mercury.lcs.mit.edu> <1494633169.1599957.975050752.2FB9B2DA@webmail.messagingengine.com> Message-ID: <1494636515.1613066.975082816.77F24338@webmail.messagingengine.com> On Fri, May 12, 2017, at 20:26, Dave Horsfall wrote: > On Fri, 12 May 2017, Random832 wrote: > > > > > if (xp->x_count!=1 || xp->x_iptr->i_mode&ISVTX) > > > > goto error; > > > > > > Err, isn't that the sticky bit, not the setuid bit? > > > > The sticky bit makes it keep the image in memory when there are no > > processes using it. I assume x_count is determining whether there are > > processes using it. So, taken together, these checks are "is there or > > might there be in the future a process, other than the one being > > debugged, using this exact copy of the image rather than loading it from > > the disk". > > I know that, but the discussion was about the SUID bit, and the ability > to > modify the in-core image of a set-uid program being run... It seems to me that this check is central to being able to (or not) modify the in-core image of any process at all other than the one being traced (say, by attaching to a SUID program that has already dropped privileges, and making changes that will affect the next time it is run).