All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: "M. Mohan Kumar" <mohan@in.ibm.com>
Cc: stefanha@gmail.com, qemu-devel@nongnu.org,
	aneesh.kumar@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH] fsdev: Don't ignore setfsuid/setfsgid return values
Date: Fri, 05 Oct 2012 05:52:54 -0600	[thread overview]
Message-ID: <506ECA16.1040109@redhat.com> (raw)
In-Reply-To: <1349426179-16712-1-git-send-email-mohan@in.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]

On 10/05/2012 02:36 AM, M. Mohan Kumar wrote:
> From: "M. Mohan Kumar" <mohan@in.ibm.com>
> 
> In current implementation of setfsuid/setfsgid there is no way to know
> if it failed by checking the return value. This patch assumes
> setfsuid/setfsgid returns -1 in case of error. Eventually kernel code
> needs to be fixed.

According to the Fedora 17 man page:

RETURN VALUE
   On success, the previous value of fsuid is  returned.   On  error,
the current value of fsuid is returned.

NOTES
      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.

BUGS
       No error messages of any kind are returned to the caller.  At the
 very least, EPERM should be returned when the call fails (because the
caller lacks the CAP_SETUID capability).

Eww - self-contradictory.  I think the reason that F17 marked these
functions warn_unused_return is because there HAS been an effort to make
these functions return sane values that can be used to detect when
errors have occurred.

> 
> Signed-off-by: M. Mohan Kumar <mohan@in.ibm.com>
> ---
>  fsdev/virtfs-proxy-helper.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/fsdev/virtfs-proxy-helper.c b/fsdev/virtfs-proxy-helper.c
> index f9a8270..ed5eede 100644
> --- a/fsdev/virtfs-proxy-helper.c
> +++ b/fsdev/virtfs-proxy-helper.c
> @@ -290,9 +290,12 @@ static int setfsugid(int uid, int gid)
>          CAP_DAC_OVERRIDE,
>      };
>  
> -    setfsgid(gid);
> -    setfsuid(uid);
> -
> +    if (setfsgid(gid) < 0) {
> +        return -errno;
> +    }
> +    if (setfsuid(uid) < 0) {
> +        return -errno;
> +    }

At any rate, this silences the compiler warning I was hitting, so:

Tested-by: Eric Blake <eblake@redhat.com>

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 617 bytes --]

      reply	other threads:[~2012-10-05 11:53 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-05  8:36 [Qemu-devel] [PATCH] fsdev: Don't ignore setfsuid/setfsgid return values M. Mohan Kumar
2012-10-05 11:52 ` Eric Blake [this message]

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=506ECA16.1040109@redhat.com \
    --to=eblake@redhat.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=mohan@in.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    /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.