From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Weimer Subject: Fixing setfsuid/setfsgid Date: Wed, 22 Jan 2014 13:40:46 +0100 Message-ID: <52DFBC4E.3060103@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To: linux-fsdevel@vger.kernel.org Return-path: Received: from mx1.redhat.com ([209.132.183.28]:12981 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755154AbaAVMks (ORCPT ); Wed, 22 Jan 2014 07:40:48 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s0MCemoE017799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 22 Jan 2014 07:40:48 -0500 Received: from oldenburg.str.redhat.com (ovpn-116-99.ams2.redhat.com [10.36.116.99]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s0MCekl2006195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 22 Jan 2014 07:40:47 -0500 Sender: linux-fsdevel-owner@vger.kernel.org List-ID: At present, setfsuid and setfsgid return the same value on success and on error, so it is rather difficult to check for errors. Since the 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. * Introduce new system calls setfsuid1, fetfsgid1 which have the usual "return -errno on failure, 0 on success" semantics. * Introduce getfsuid, getfsgid, so that applications can check for failure by noting that the fs?id did not change. These system calls might have other uses as well. Emulation in glibc by parsing /proc/self/status is possible. * Don't bother with fs?id at all anymore and attach effective security 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 umask and security contexts. This would need new system calls fsetuid, fsetgid, and probably socketat (for bind/connect) and perhaps socketpairat. Comments? -- Florian Weimer / Red Hat Product Security Team