Date: Sun, 17 Jan 2016 11:05:15 +0300 From: Chagin Dmitry <dchagin@freebsd.org> To: Konstantin Belousov <kib@kib.kiev.ua> Cc: Mateusz Guzik <mjguzik@gmail.com>, Vijay Singh <vijju.singh@gmail.com>, freebsd-hackers@freebsd.org Subject: Re: irrelevant locking Message-ID: <20160117080515.GA32432@chd.heemeyer.club> In-Reply-To: <20160117034315.GN3942@kib.kiev.ua> References: <20160116195819.GA41610@chd.heemeyer.club> <20160116202643.GL3942@kib.kiev.ua> <CALCNsJT_gH5gJaB%2ByVQRcON84JntSUevG8-X-0Z5_13DkPC%2BBg@mail.gmail.com> <20160116224312.GA1963@dft-labs.eu> <20160117034315.GN3942@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 17, 2016 at 05:43:15AM +0200, Konstantin Belousov wrote: > 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. Thank you, guys, for your response. > > > > > 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. like a Linux AT_SECURE? our P_SUGID bit can be changed after exec, so the result of issetugid() implementated on auxv table will be unnafected by calls to setuid(), setgid() or other such calls.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160117080515.GA32432>