From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boaz Harrosh Subject: Re: [5/8] syscall_cred() a system call that receives alternate CREDs Date: Tue, 9 Apr 2013 00:33:32 +0300 Message-ID: <516337AC.6030707@panasas.com> References: <516299A5.8030109@panasas.com> <3325648.XNlCoRUAAr@jlieb-e6410> <20130408183119.GC4442@pad.fieldses.org> <1522251.bVHhpLrEx2@jlieb-e6410> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: "J. Bruce Fields" , Frank S Filz , Steven Whitehouse , Steve Dickson , Jeff Layton , , linux-fsdevel , Venkateswararao Jujjuri , DENIEL Philippe To: Jim Lieb Return-path: Received: from natasha.panasas.com ([67.152.220.90]:56201 "EHLO natasha.panasas.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965137Ab3DHVeG (ORCPT ); Mon, 8 Apr 2013 17:34:06 -0400 In-Reply-To: <1522251.bVHhpLrEx2@jlieb-e6410> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 08/04/13 22:45, Jim Lieb wrote: > We are setting user, primary group, and alt groups in sequence before we do > the actual work (read/write/...). This is a potential TOCTOU race. Granted, > there is little/no real atomic guarantee but implied in the syscall model is > that creds don't change for the duration of a syscall. We go back to > userspace multiple times with creds in intermediate state(s). Signals can > happen anytime but are only checked on the way back out of the syscall or we > can hold them off at critical times within a single syscall. Which syscall is > is the one where the signal occurred? In our case, we minimally use signals > (do no i/o etc.) but they are still there. If it is one syscall, we know. > signals are crap long before our case. I would not really care about signals. The performance argument is good enough for me. > We currently have an RFC implementation of a "creds wrapper" but it is still > in flux and the codiing of all these calls to "get it right" is ugly. One > call, done right would be much better. > > We also have a problem with the setgroups. We escape in Linux because the > kernel doesn't do it process wide and glibc fakes it. I don't want to depend > on that. In FreeBSD, we can't do it at all since the creds are shared at the Sachin found that FBSD might be exactly the same as Linux here. Please talk to him to make sure? > proc level. Note that I am constrained to think about portability and it's > easier to sell a new syscall than to hack fundamental kernel structures which > is why the "do to all" bit is in glibc... > But yes a new syscall with new defined semantics is definitely a better way to go. Just for the sake of thread_setgroups such a call is well worth it. Completely bypass POSIX and be done with it. So strongly yes here. Bruce, got the point? Current code with the undocumented thread_setgroups is a POSIX hack. And will break at any given moment in time. Only a new syscall with defined semantics will ever be correct. Thanks Boaz