[libvirt] [PATCH 2/2] util: Don't fail virGetGroupIDByName when group not found

Peter Krempa pkrempa at redhat.com
Thu Dec 6 14:08:05 UTC 2012


On 12/05/12 13:03, Christophe Fergeau wrote:
> virGetGroupIDByName is documented as returning 1 if the groupname
> cannot be found. getgrnam_r is documented as returning:
> « 0 or ENOENT or ESRCH or EBADF or EPERM or ...  The given name
> or gid was not found. »
>   and that:
> « The formulation given above under "RETURN VALUE" is from POSIX.1-2001.
> It  does  not  call  "not  found"  an error, hence does not specify what
> value errno might have in this situation.  But that makes it impossible to
> recognize errors.  One might argue that according to POSIX errno should be
> left unchanged if an entry is not found.  Experiments on various UNIX-like
> systems shows that lots of different values occur in this situation: 0,
> ENOENT, EBADF, ESRCH, EWOULDBLOCK, EPERM and probably others. »
>
> virGetGroupIDByName returns an error when the return value of getgrnam_r
> is non-0. However on my RHEL system, getgrnam_r returns ENOENT when the
> requested user cannot be found, which then causes virGetGroupID not
> to behave as documented (it returns an error instead of falling back
> to parsing the passed-in value as an gid).
>
> This commit makes virGetGroupIDByName ignore the various values listed
> in getgrnam_r manpage and return a 'group not found' result in such
> cases.
> ---
>   src/util/util.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/util/util.c b/src/util/util.c
> index df1af7e..e9474dd 100644
> --- a/src/util/util.c
> +++ b/src/util/util.c
> @@ -2613,7 +2613,8 @@ virGetGroupIDByName(const char *name, gid_t *gid)
>           }
>       }
>
> -    if (rc != 0) {
> +    if ((rc != 0) && (rc != ENOENT) && (rc != ESRCH)
> +                  && (rc != EBADF) && (rc != EPERM)) {
>           virReportSystemError(rc, _("Failed to get group record for name '%s'"),
>                                name);
>           goto cleanup;
>

ACK with same conditions as in my review of 1/2 in this series.

Peter




More information about the libvir-list mailing list