[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#10021: [PATCH id] Add error-checking on GNU

From: Eric Blake
Subject: Re: bug#10021: [PATCH id] Add error-checking on GNU
Date: Mon, 14 Nov 2011 12:12:35 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1

On 11/14/2011 11:54 AM, Paul Eggert wrote:
>    else
>      {
> +      /* On GNU hosts, getuid etc. can fail and return -1.  On POSIX
> +         hosts, such failures are not allowed and (uid_t) -1 may be a
> +         valid UID if uid_t is unsigned.

That doesn't read correctly.  You are correct that POSIX states that
getuid() cannot fail in a conforming environment (therefore, the only
way that GNU getuid fails is if you have done something outside the
realms of a conforming environment).  However, POSIX is quite clear that
chown() must honor (uid_t)(-1) as a means of not altering the uid of a
file, therefore, POSIX explicitly rejects (uid_t)(-1) as a valid UID.

POSIX leaves it up to the implementation whether the type uid_t is
signed or unsigned, but also specifies that valid uids are non-negative
integers (so if uid_t is signed, half the possible values will never be
encountered as valid uids).

>  To handle both cases
> +         correctly, consider getuid etc. to fail if it returns a
> +         negative value.

But if uid_t is an unsigned type (which POSIX permits), then it will
never be a negative value.

> +
> +         POSIX hosts should not give users a UID equal to (uid_t) -1
> +         even if uid_t is unsigned, as system calls like chown would
> +         behave unexpectedly with such a UID, and in general coreutils
> +         therefore does not support such a UID.  However, 'id' makes a
> +         special attempt to handle it, if only to help people diagnose
> +         the problem.  */
> +
>        euid = geteuid ();
> -      if (GETID_MAY_FAIL && euid == -1 && !use_real
> +      if (euid < 0 && !use_real

That is, how can this work?  On systems where uid_t is signed, it makes
sense, but on systems where uid_t is unsigned, this will always be false
(and probably trigger a gcc warning), and still fail to catch the
(uid_t)(-1) case that we are trying to diagnose.

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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]