From owner-freebsd-hackers@freebsd.org Sun Jan 17 03:43:23 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C3ACA6A448 for ; Sun, 17 Jan 2016 03:43:23 +0000 (UTC) (envelope-from kib@kib.kiev.ua) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E95C11094; Sun, 17 Jan 2016 03:43:22 +0000 (UTC) (envelope-from kib@kib.kiev.ua) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u0H3hFuX097709 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 17 Jan 2016 05:43:16 +0200 (EET) (envelope-from kib@kib.kiev.ua) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u0H3hFuX097709 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kib.kiev.ua; s=tom; t=1453002199; bh=vh3gUg9oKo6StODkSiGZd8lfG4yv0RgNYbRcbsui6Ls=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=dMRR0SyDgCu5wRDANNTkIbWEb8hXNBbzcTcONwh5UdRJ6H8kBZe+SiMcQBlYrKB34 B7nrVl3DpeDvsRVIWUxv0mKt0vX+qc3ZiCRBIMs+A/sepl4/rnppAvZ7GG6iBiB3Th sbh9DOQXAQhRnaoNUNdtWhPnknbPVGumvrCbDAdI= Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u0H3hF2q097708; Sun, 17 Jan 2016 05:43:15 +0200 (EET) (envelope-from kib@kib.kiev.ua) X-Authentication-Warning: tom.home: kostik set sender to kib@kib.kiev.ua using -f Date: Sun, 17 Jan 2016 05:43:15 +0200 From: Konstantin Belousov To: Mateusz Guzik Cc: Vijay Singh , freebsd-hackers@freebsd.org, Chagin Dmitry Subject: Re: irrelevant locking Message-ID: <20160117034315.GN3942@kib.kiev.ua> References: <20160116195819.GA41610@chd.heemeyer.club> <20160116202643.GL3942@kib.kiev.ua> <20160116224312.GA1963@dft-labs.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="E13BgyNx05feLLmH" Content-Disposition: inline In-Reply-To: <20160116224312.GA1963@dft-labs.eu> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-Mailman-Approved-At: Sun, 17 Jan 2016 04:41:41 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 03:43:23 -0000 --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--