13 May
2017
13 May
'17
6:48 a.m.
On Fri, May 12, 2017, at 20:26, Dave Horsfall wrote:
On Fri, 12 May 2017, Random832 wrote:
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).
if (xp->x_count!=1 ||
xp->x_iptr->i_mode&ISVTX)
goto error;
Err, isn't that the sticky bit, not the setuid bit?