From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51959) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tfxf9-0005MR-Jl for qemu-devel@nongnu.org; Tue, 04 Dec 2012 13:56:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tfxf0-000523-Pt for qemu-devel@nongnu.org; Tue, 04 Dec 2012 13:56:11 -0500 Received: from e28smtp05.in.ibm.com ([122.248.162.5]:56393) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tfxf0-00051f-0K for qemu-devel@nongnu.org; Tue, 04 Dec 2012 13:56:02 -0500 Received: from /spool/local by e28smtp05.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 5 Dec 2012 00:25:53 +0530 From: "Aneesh Kumar K.V" In-Reply-To: <5076BACC.7030309@redhat.com> References: <1349868762-10021-1-git-send-email-pbonzini@redhat.com> <50759EEC.8070308@weilnetz.de> <50759F9E.3060800@redhat.com> <5075A0FF.3080904@weilnetz.de> <5075A420.10003@redhat.com> <5075A843.8020107@weilnetz.de> <5075A966.3090708@weilnetz.de> <871uh5tqr7.fsf@explorer.in.ibm.com> <5076BACC.7030309@redhat.com> Date: Wed, 05 Dec 2012 00:25:55 +0530 Message-ID: <87y5hdejes.fsf@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH] virtfs-proxy-helper: check return code of setfsgid/setfsuid List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , "M. Mohan Kumar" Cc: qemu-trivial@nongnu.org, Stefan Weil , qemu-devel@nongnu.org Paolo Bonzini writes: > Il 11/10/2012 09:25, M. Mohan Kumar ha scritto: >> Also as per the man page: >> When glibc determines that the argument is not a valid user ID, >> it will return -1 and set errno to EINVAL >> without attempting the system call. >> >> If it mean a nonexistent id by 'not a valid user ID' it may be a >> problem in virtfs case. > > I think only -1 would be an invalid user ID, or perhaps a user ID > > 65535 if the kernel only supports 16-bit user IDs. > > Rather than dealing with the kernel, can we just use > setresuid/setresgid like in the following (untested) patch? > > Paolo > > ps: so far in my short life I had managed to stay away from privilege > dropping, so please review with extra care. > > ------------------- 8< ----------------------- > From: Paolo Bonzini > Date: Thu, 11 Oct 2012 14:20:23 +0200 > Subject: [PATCH] virtfs-proxy-helper: use setresuid and setresgid > > The setfsuid and setfsgid system calls are obscure and they complicate > the error checking (that glibc's warn_unused_result "feature" forces > us to do). Switch to the standard setresuid and setresgid functions. > > --- > diff --git a/fsdev/virtfs-proxy-helper.c b/fsdev/virtfs-proxy-helper.c > index f9a8270..07b3b5b 100644 > --- a/fsdev/virtfs-proxy-helper.c > +++ b/fsdev/virtfs-proxy-helper.c > @@ -272,31 +272,76 @@ static int send_status(int sockfd, struct iovec *iovec, int status) > /* > * from man 7 capabilities, section > * Effect of User ID Changes on Capabilities: > - * 4. If the file system user ID is changed from 0 to nonzero (see setfsuid(2)) > - * then the following capabilities are cleared from the effective set: > - * CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, CAP_FOWNER, CAP_FSETID, > - * CAP_LINUX_IMMUTABLE (since Linux 2.2.30), CAP_MAC_OVERRIDE, and CAP_MKNOD > - * (since Linux 2.2.30). If the file system UID is changed from nonzero to 0, > - * then any of these capabilities that are enabled in the permitted set > - * are enabled in the effective set. > + * If the effective user ID is changed from nonzero to 0, then the permitted > + * set is copied to the effective set. If the effective user ID is changed > + * from 0 to nonzero, then all capabilities are are cleared from the effective > + * set. > + * > + * The setfsuid/setfsgid man pages warn that changing the effective user ID may > + * expose the program to unwanted signals, but this is not true anymore: for an > + * unprivileged (without CAP_KILL) program to send a signal, the real or > + * effective user ID of the sending process must equal the real or saved user > + * ID of the target process. Even when dropping privileges, it is enough to > + * keep the saved UID to a "privileged" value and virtfs-proxy-helper won't > + * be exposed to signals. So just use setresuid/setresgid. > */ > -static int setfsugid(int uid, int gid) > +static int setugid(int uid, int gid, int *suid, int *sgid) > { > + int retval; > + > /* > - * We still need DAC_OVERRIDE because we don't change > + * We still need DAC_OVERRIDE because we don't change > * supplementary group ids, and hence may be subjected DAC rules > */ > cap_value_t cap_list[] = { > CAP_DAC_OVERRIDE, > }; > > - setfsgid(gid); > - setfsuid(uid); > + /* > + * If suid/sgid are NULL, the saved uid/gid is set to the > + * new effective uid/gid. If they are not, the saved uid/gid > + * is set to the current effective user id and stored into > + * *suid and *sgid. > + */ > + if (!suid) { > + suid = &uid; > + } else { > + *suid = geteuid(); > + } > + if (!sgid) { > + sgid = &gid; > + } else { > + *sgid = getegid(); > + } > + I found this to be confusing. How about avoiding all those pointers, something like below ? If you are ok can I add the signed-off-by for this ? I can test this and get a pull request out with the build fix. commit 24cc9f0d07c2a505bfafbdcb72006f2eda1288a4 Author: Paolo Bonzini Date: Thu Oct 11 14:20:23 2012 +0200 virtfs-proxy-helper: use setresuid and setresgid The setfsuid and setfsgid system calls are obscure and they complicate the error checking (that glibc's warn_unused_result "feature" forces us to do). Switch to the standard setresuid and setresgid functions. diff --git a/fsdev/virtfs-proxy-helper.c b/fsdev/virtfs-proxy-helper.c index f9a8270..49ab0eb 100644 --- a/fsdev/virtfs-proxy-helper.c +++ b/fsdev/virtfs-proxy-helper.c @@ -272,31 +272,59 @@ static int send_status(int sockfd, struct iovec *iovec, int status) /* * from man 7 capabilities, section * Effect of User ID Changes on Capabilities: - * 4. If the file system user ID is changed from 0 to nonzero (see setfsuid(2)) - * then the following capabilities are cleared from the effective set: - * CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, CAP_FOWNER, CAP_FSETID, - * CAP_LINUX_IMMUTABLE (since Linux 2.2.30), CAP_MAC_OVERRIDE, and CAP_MKNOD - * (since Linux 2.2.30). If the file system UID is changed from nonzero to 0, - * then any of these capabilities that are enabled in the permitted set - * are enabled in the effective set. + * If the effective user ID is changed from nonzero to 0, then the permitted + * set is copied to the effective set. If the effective user ID is changed + * from 0 to nonzero, then all capabilities are are cleared from the effective + * set. + * + * The setfsuid/setfsgid man pages warn that changing the effective user ID may + * expose the program to unwanted signals, but this is not true anymore: for an + * unprivileged (without CAP_KILL) program to send a signal, the real or + * effective user ID of the sending process must equal the real or saved user + * ID of the target process. Even when dropping privileges, it is enough to + * keep the saved UID to a "privileged" value and virtfs-proxy-helper won't + * be exposed to signals. So just use setresuid/setresgid. */ -static int setfsugid(int uid, int gid) +static int setugid(int uid, int gid, int suid, int sgid) { + int retval; + /* - * We still need DAC_OVERRIDE because we don't change + * We still need DAC_OVERRIDE because we don't change * supplementary group ids, and hence may be subjected DAC rules */ cap_value_t cap_list[] = { CAP_DAC_OVERRIDE, }; - setfsgid(gid); - setfsuid(uid); + if (setresuid(-1, uid, suid) == -1) { + retval = -errno; + goto err_out; + } + if (setresgid(-1, gid, sgid) == -1) { + retval = -errno; + goto err_suid; + } if (uid != 0 || gid != 0) { - return do_cap_set(cap_list, ARRAY_SIZE(cap_list), 0); + if (do_cap_set(cap_list, ARRAY_SIZE(cap_list), 0) < 0) { + retval = -errno; + goto err_sgid; + } } + return 0; + +err_sgid: + if (setresgid(-1, sgid, sgid) == -1) { + abort(); + } +err_suid: + if (setresuid(-1, suid, suid) == -1) { + abort(); + } +err_out: + return retval; } /* @@ -586,9 +614,8 @@ static int do_create_others(int type, struct iovec *iovec) return retval; } offset += retval; - retval = setfsugid(uid, gid); + retval = setugid(uid, gid, cur_uid, cur_gid); if (retval < 0) { - retval = -errno; goto err_out; } switch (type) { @@ -621,7 +648,7 @@ static int do_create_others(int type, struct iovec *iovec) err_out: v9fs_string_free(&path); v9fs_string_free(&oldpath); - setfsugid(cur_uid, cur_gid); + setugid(cur_uid, cur_gid, cur_uid, cur_gid); return retval; } @@ -641,24 +668,20 @@ static int do_create(struct iovec *iovec) if (ret < 0) { goto unmarshal_err_out; } + cur_uid = geteuid(); cur_gid = getegid(); - ret = setfsugid(uid, gid); + ret = setugid(uid, gid, cur_uid, cur_gid); if (ret < 0) { - /* - * On failure reset back to the - * old uid/gid - */ - ret = -errno; - goto err_out; + goto unmarshal_err_out; } ret = open(path.data, flags, mode); if (ret < 0) { ret = -errno; } -err_out: - setfsugid(cur_uid, cur_gid); + setugid(cur_uid, cur_gid, cur_uid, cur_gid); + unmarshal_err_out: v9fs_string_free(&path); return ret;