irrelevant locking

[Konstantin Belousov]

On Sat, Jan 16, 2016 at 11:43:13PM +0100, Mateusz Guzik wrote:
> On Sat, Jan 16, 2016 at 02:08:58PM -0800, Vijay Singh wrote:
> > Couldn't the get & set race otherwise?
> 
> Current locking plays no role in correctness here.
> 
> Say that locking is left in place. A concurrent setgroups (or whatever)
> call resulting in setting P_SUGID is also being executed. Regardless of
> whether PROC_LOCK/PROC_UNLOCK pair is in place, it can set the bit
> before or after it is being tested by sys_issetugid.
> 
> In principle, the very moment you drop a lock, your informatoin is
> stale.
Right, this is the reason why the locking is useless.

> 
> This does not matter here. It's only the process itself which can set
> the bit, so it would have to race with itself.
One thread in the process executing issetugid() can race with another
executing setsugid().  It is legitimate.

> 
> Finally, the bit can be only unset during execve, which cannot be
> executed here - if it is being executed, there is only one thread doing
> work and, well, it is doing execve.
> 
> The real question is if it would make sense to add the bit to elf aux
> vector to save the call as done by the loader.
I once did a pass to remove (most of) sysctls executed during process
startup.  issetugid indeed may be treated same.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20160117/18d15a89/attachment.sig>