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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list