Date: Sun, 17 Jan 2016 05:43:15 +0200 From: Konstantin Belousov <kib@kib.kiev.ua> To: Mateusz Guzik <mjguzik@gmail.com> Cc: Vijay Singh <vijju.singh@gmail.com>, freebsd-hackers@freebsd.org, Chagin Dmitry <dchagin@freebsd.org> Subject: Re: irrelevant locking Message-ID: <20160117034315.GN3942@kib.kiev.ua> In-Reply-To: <20160116224312.GA1963@dft-labs.eu> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--E13BgyNx05feLLmH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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? >=20 > Current locking plays no role in correctness here. >=20 > 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. >=20 > In principle, the very moment you drop a lock, your informatoin is > stale. Right, this is the reason why the locking is useless. >=20 > 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. >=20 > 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. >=20 > 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. --E13BgyNx05feLLmH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWmw3TAAoJEJDCuSvBvK1BDTAP/i3TRqSzLPeFoIGrWnowQCqW eQ8mza7NnCTO9NJmAGUGJCFtRhD3BBMD0IUfKrRvLxC0rk9Bzpvnhgu+Df3EWNZk OvEeAgrTyzLQNs5NQ9MY0IlC9wlM5k3Yz+dawEy1x0/CfnOcg6DDWKrb7FYwWhAb BfVq/TCZ2AMUDP3cDTgY+9awgfMcTBppCnWWjV6TJ+R6JdEoB/IKkaoFIPkHKf2e 48bqKMtVMbB+PZd61z86K4H7PeQqA3CNTiFfrJzV7hsf1G0oEeX/q+Pc6AIYrf1Q 5WzYliHZEd8fnZhFwMZV5DjS/htd+f8zOklIaaKdFk7bQeEVKVuQmDHafRIQlZE+ DsXHe7orym/H7RQTCLbY/DuGnQblQpfupE9U7Lvetwx45S1/byxMExoPFkpfX63W emgi28vPqhctD7Yg+e1wz8ITpcX7F6oUoCrIun07YeeQ715bCUqOTuv+kxiEIa0u /ghkFQyN+mHlZ0m1SpO4zmXdcw7cFEYuODRm/0Sr9TGl3B6LOvlKNUbLvGgeFTFa ToYFRp5yQ3ev5HA1/AiKMWFeJ/scSsXXOFkgWCUGNJULwAsXuy2Go9VMUvaeErj3 JRdu/udV0NZVVLWpwM7XXJuvpEqxsYcNIJ08bL1bfe/vyPGUTWt8SuXrkBW7lToP 9uQWcT/oRVmZJVldikFQ =6zii -----END PGP SIGNATURE----- --E13BgyNx05feLLmH--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160117034315.GN3942>