From owner-freebsd-hackers@freebsd.org Sat Jan 16 22:43:18 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 8C47AA848C4 for ; Sat, 16 Jan 2016 22:43:18 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1D5D218F8; Sat, 16 Jan 2016 22:43:18 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id b14so72943901wmb.1; Sat, 16 Jan 2016 14:43:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=szM6ppiBrti+zk2gWjRhH/UEfArv5uqnw4Kl5nXH9AE=; b=mOy7xCOAOlfkDgND7TQBfqf5ABe3wEUy27IK17Qn/gTVCFWVQLEIhHR7+ppeouhC8i FV/5MrvLSfaxyz1vlLMs1n8AxyGFLYeJ2ftGjq/Mxh6OmnmAtZIaP6VmSjcmYQvc12al BRTfFjjLTCP5PfUB3ajpthY0vskOZiTMK9B8NdKvbUo8CL6vbCAtD4tmOiOYegPpMY6R eC11LEjARcE6jnTLEm5t7qXcsiIRSDN4JTxiuDJCUExNrspQgdF0HpVCYf1jTdf5prRW Y19lCXkPqRUS6isEMzO7+VNmRoNluFh7SeuQslqQBLLk/dx0NOHy3pymoM9txV1SMh9O CHyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=szM6ppiBrti+zk2gWjRhH/UEfArv5uqnw4Kl5nXH9AE=; b=TO7B20deQagfcjTOpyw2YgStgw97Jgt0tbMhWwjkh5gDJrjAo+x6lhafsNmaXvtD6W oCf3b5mgKZsrugQcwRk+/7WPCMt7pX7aCvAtrEQnb+kGwI5eF8pC8bIX9XutUC6l/JMC EkWZLnxHCEOJ8yLW/R9NDElsrrvpmia8zvaPiBQVRq2E1kYojtLTJwbV3rqaX1vfwReC 0K0Y15Ybu53GjqkNqs7KPan8WyL1OPEyifU/PVqd2oofVI/mtx/ZmQytvEXlr1humIZG YD3BW9nD9tSBY2YULUrsOHvzqWVuKtt98knGFQ8z04NQzUXxmvz34ikzUnOGKsGjQL4U 8nEg== X-Gm-Message-State: AG10YOQWj2tIh96tI30vxaDzdrQdZfqHlF96OsynHoHPks4LNNOudoVYZemmKM8Ja4I8rQ== X-Received: by 10.28.127.85 with SMTP id a82mr5896826wmd.48.1452984195574; Sat, 16 Jan 2016 14:43:15 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by smtp.gmail.com with ESMTPSA id 75sm8663307wmo.22.2016.01.16.14.43.14 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Sat, 16 Jan 2016 14:43:15 -0800 (PST) Date: Sat, 16 Jan 2016 23:43:13 +0100 From: Mateusz Guzik To: Vijay Singh Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, Chagin Dmitry Subject: Re: irrelevant locking Message-ID: <20160116224312.GA1963@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Vijay Singh , Konstantin Belousov , freebsd-hackers@freebsd.org, Chagin Dmitry References: <20160116195819.GA41610@chd.heemeyer.club> <20160116202643.GL3942@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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: Sat, 16 Jan 2016 22:43:18 -0000 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. This does not matter here. It's only the process itself which can set the bit, so it would have to race with itself. 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. > On Jan 16, 2016 12:27 PM, "Konstantin Belousov" wrote: > > > On Sat, Jan 16, 2016 at 10:58:19PM +0300, Chagin Dmitry wrote: > > > hi, please, can someone explain the reason to take the process lock here: > > There is no reason, I think that the PROC_LOCK() can be removed. > > > > > > > > int > > > sys_issetugid(register struct thread *td, struct issetugid_args *uap) > > > { > > > struct proc *p = td->td_proc; > > > > > > /* > > > * Note: OpenBSD sets a P_SUGIDEXEC flag set at execve() time, > > > * we use P_SUGID because we consider changing the owners as > > > * "tainting" as well. > > > * This is significant for procs that start as root and "become" > > > * a user without an exec - programs cannot know *everything* > > > * that libc *might* have put in their data segment. > > > */ > > > PROC_LOCK(p); > > > td->td_retval[0] = (p->p_flag & P_SUGID) ? 1 : 0; > > > PROC_UNLOCK(p); > > > return (0); > > > } > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Mateusz Guzik