From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Lieb Subject: Re: Re: Fixing setfsuid/setfsgid Date: Wed, 22 Jan 2014 10:21:28 -0800 Message-ID: <5725197.TtPkkAW1pH@jlieb-e6410> References: <52DFBC4E.3060103@redhat.com> <20140122085653.7718752e@tlielax.poochiereds.net> <52DFD049.7070605@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Jeff Layton , To: Florian Weimer Return-path: Received: from natasha.panasas.com ([209.166.131.148]:48603 "EHLO natasha.panasas.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752437AbaAVTxw convert rfc822-to-8bit (ORCPT ); Wed, 22 Jan 2014 14:53:52 -0500 In-Reply-To: <52DFD049.7070605@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wednesday, January 22, 2014 15:06:01 Florian Weimer wrote: > On 01/22/2014 02:56 PM, Jeff Layton wrote: > > On Wed, 22 Jan 2014 13:40:46 +0100 > >=20 > > Florian Weimer wrote: > >> At present, setfsuid and setfsgid return the same value on success= and > >> on error, so it is rather difficult to check for errors. Since th= e > >> userns changes at least, failure can not only be caused by lack of= the > >> CAP_SETUID capability, but also by an out-of-memory situation. > >=20 > > It is awkward, but how is it ambiguous? If you get back the same va= lue > > you passed in, then you know that nothing changed. >=20 > It returns the old value, not the new value, just like umask. >=20 > >> * Introduce new system calls setfsuid1, fetfsgid1 which have the u= sual > >> "return -errno on failure, 0 on success" semantics. > >>=20 > >> * Introduce getfsuid, getfsgid, so that applications can check for > >> failure by noting that the fs?id did not change. These system cal= ls > >> might have other uses as well. Emulation in glibc by parsing > >> /proc/self/status is possible. > >=20 > > #2 sounds quite reasonable. It's simple, and having a setfsuid() > > without a way to definitively fetch the current value is dumb. >=20 > Yes, it's certainly simple, and we can try to do some magic in glibc = to > deprecate looking at the return value of setfsuid. getumask seems to > missing as well. >=20 > >> * Don't bother with fs?id at all anymore and attach effective secu= rity > >> information to descriptors, which are then inherited by the *at > >> functions. This is far more invasive, but would solve the > >> multi-threading ambiguity and could be reasonably extended to umas= k and > >> security contexts. This would need new system calls fsetuid, fset= gid, > >> and probably socketat (for bind/connect) and perhaps socketpairat. > >=20 > > (cc'ing Jim Lieb) > >=20 > > I know that Jim had been working on something along these lines, bu= t I > > don't know the current state of that work... >=20 > Interesting, thanks. It is still in the works although it has been delayed while I got V2.0 = of nfs- ganesha out and, of course, the holidays. I plan to get back to it as = soon as=20 my current nfs-ganesha dev task is done. I proposed a switch_creds syscall in mid-Oct (a couple of versions). T= he last=20 round ended with Tetso Handa pointing out a BUG() issue with override_c= reds in=20 that it is possible to trigger the BUG() in between a switch_creds and = its=20 revert. This only affects the thread that does this call but I have to= get=20 back to it and chase down all the cases. An override/revert can only w= ork=20 presently inside the kernel for a single syscall that uses them. Ultim= ately I=20 don't think it will be a problem. All the in-kernel cases are covered = now and=20 I just need to identify which syscalls are affected and whether the BUG= () can=20 be turned into an error return that doesn't break backwards compatibili= ty. You are right. These syscalls are a bit strange and certainly not what= we=20 need for nfs-ganesha and probably for samba (and others) as well. Erro= r=20 handling is at best "by inference" aka crap. I'm not really interested= in=20 another set of syscalls unless we can fix some other problems as well. 1. Setting fsuid/gid is not enough. We also need to do a setgroups. 2. RCU is great but sloshing thru 6 of these calls (3 in + 3 out) is no= t good. 3. Using something similar to knfsd's nfsd_setuser() (what these calls = do) is=20 clean and efficient. The only current stumbling block is the BUG case = above. 4. Actually throw real errors like EPERM instead of fiddling returned u= ids... It would be great if we can work together and get something we all need= here. I can send along the current patch set for you to review. Like I said,= I need=20 to do more to deal with the BUG() call in commit_creds(). Jim --=20 Jim Lieb Linux Systems Engineer Panasas Inc. "If ease of use was the only requirement, we would all be riding tricyc= les" - Douglas Engelbart 1925=E2=80=932013 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html