Bug 883547 - virGetUserIDByName and virGetUserIDByName returns error when a nsswitch service is unavailable
virGetUserIDByName and virGetUserIDByName returns error when a nsswitch servi...
Status: CLOSED NEXTRELEASE
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Krempa
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-04 15:46 EST by Asad Saeed
Modified: 2012-12-16 16:53 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-16 16:53:12 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Asad Saeed 2012-12-04 15:46:03 EST
Description of problem:
In the released 1.0.0 version of libvirt running on a rhel/centos 6.2 version, I am getting the following error when starting a domain via libvirt.

QEMU log for the domain:
libvir:  error : Failed to get user record for name '107': No such file or directory.
libvirtd.log:
2012-12-04 20:35:27.759+0000: 10419: error : virCommandHandshakeWait:2428 : internal error Failed to get user record for name '107': No such file or directory

I have tracked down this issue to a service being unavailable in nsswitch.conf. In this case it was winbind (which is used for our samba users).  If the winbind service is unavailable when the domain is started, tt seems that both the getpwnam_r and getgrnam_r calls return ENOENT for unknown users.

My nsswitch.conf contains 
passwd:     files winbind
shadow:     files winbind
group:      files winbind

Version-Release number of selected component (if applicable):
1.0.0 - libvirtd
nss-3.13.1-7.el6_2.x86_64

How reproducible:
Reproducible when unavailable nsswitch service.

Steps to Reproduce:
1. Add unavailable service to nsswitch.conf
2. Start domain
  
Additional info:
Comment 1 Christophe Fergeau 2012-12-15 08:20:03 EST
Is it still happening with these upstream patches?


commit a33f4eae83ecc6fb6e33006650c7f81e16584bd0
Author: Christophe Fergeau <cfergeau@redhat.com>
Date:   Wed Dec 5 11:21:10 2012 +0100

    util: Don't fail virGetGroupIDByName when group not found
    
    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 only report an error when errno
    is set to one of the values in the posix description of getgrnam_r
    (which are the same as the ones described in the manpage on my system).

commit 6c6c03dc0e66db400beacc4453efa6e10ec08260
Author: Christophe Fergeau <cfergeau@redhat.com>
Date:   Wed Dec 5 11:21:10 2012 +0100

    util: Don't fail virGetUserIDByName when user not found
    
    virGetUserIDByName is documented as returning 1 if the username
    cannot be found. getpwnam_r is documented as returning:
    « 0 or ENOENT or ESRCH or EBADF or EPERM or ...  The given name
    or uid 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. »
    
    virGetUserIDByName returns an error when the return value of getpwnam_r
    is non-0. However on my RHEL system, getpwnam_r returns ENOENT when the
    requested user cannot be found, which then causes virGetUserID not
    to behave as documented (it returns an error instead of falling back
    to parsing the passed-in value as an uid).
    
    This commit makes virGetUserIDByName only report an error when errno
    is set to one of the values in the posix description of getpwnam_r
    (which are the same as the ones described in the manpage on my system).
Comment 2 Peter Krempa 2012-12-16 16:53:12 EST
The upstream patches mentioned and a few cleanups to the code that are part of the upcoming release fix this issue, so I'm closing this bug. If this issue appears again with libvirt-1.0.1 that will be released next week or a later release please feel free to reopen this bug.

Note You need to log in before you can comment on or make changes to this bug.