From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Paolo Bonzini <pbonzini@redhat.com>, "M. Mohan Kumar" <mohan@in.ibm.com>
Cc: qemu-trivial@nongnu.org, Stefan Weil <sw@weilnetz.de>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH] virtfs-proxy-helper: check return code of setfsgid/setfsuid
Date: Wed, 05 Dec 2012 00:25:55 +0530 [thread overview]
Message-ID: <87y5hdejes.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <5076BACC.7030309@redhat.com>
Paolo Bonzini <pbonzini@redhat.com> 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 <pbonini@redhat.com>
> 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 <pbonini@redhat.com>
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;
next prev parent reply other threads:[~2012-12-04 18:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-10 11:32 [Qemu-trivial] [PATCH] virtfs-proxy-helper: check return code of setfsgid/setfsuid Paolo Bonzini
2012-10-10 16:14 ` [Qemu-trivial] [Qemu-devel] " Stefan Weil
2012-10-10 16:17 ` Paolo Bonzini
2012-10-10 16:23 ` Stefan Weil
2012-10-10 16:36 ` Paolo Bonzini
2012-10-10 16:54 ` Stefan Weil
2012-10-10 16:59 ` Stefan Weil
2012-10-11 7:25 ` M. Mohan Kumar
2012-10-11 12:25 ` Paolo Bonzini
2012-12-04 18:55 ` Aneesh Kumar K.V [this message]
2012-12-05 6:59 ` M. Mohan Kumar
2012-12-05 8:35 ` Aneesh Kumar K.V
2012-12-05 12:37 ` Paolo Bonzini
2012-12-12 13:52 ` [Qemu-trivial] " Paolo Bonzini
2012-12-12 16:50 ` Aneesh Kumar K.V
2012-10-10 17:00 ` [Qemu-trivial] [Qemu-devel] " Paolo Bonzini
2012-10-10 17:58 ` Eric Blake
2012-10-10 17:55 ` Eric Blake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y5hdejes.fsf@linux.vnet.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=mohan@in.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-trivial@nongnu.org \
--cc=sw@weilnetz.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.