Re: [Xen-devel] [PATCH] libxl: Be more careful with error handling in libxl__dm_runas_helper()

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Tue, 2015-12-01 at 10:32 -0500, Boris Ostrovsky wrote:
> On 12/01/2015 09:38 AM, Ian Campbell wrote:
> > On Mon, 2015-11-30 at 13:24 -0500, Boris Ostrovsky wrote:
> > > ÂÂÂÂÂÂroot@orochi-c> cat /etc/redhat-release
> > > ÂÂÂÂÂÂFedora release 20 (Heisenbug)
> > > ÂÂÂÂÂÂroot@orochi-c> ./a.out foobar
> > > ÂÂÂÂÂÂs = 2 errno = 2 result = (nil)
> > > ÂÂÂÂÂÂgetpwnam_r: No such file or directory
> > > ÂÂÂÂÂÂroot@orochi-c>
> > > 
> > > which does look like a bug in F20 since the code above is taken from
> > > man
> > > pages' EXAMPLE and doesn't look like it works as intended (which was
> > > to
> > > produce "Not found" string)
> > https://bugzilla.redhat.com/show_bug.cgi?id=988068 seems related
> > (although
> > is blaming "sssd" rather than glibc it seems).
> 
> This too:
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=17922
> 
> They claim that glibc v2.20 fails (i.e. returns non-zero/ENOENT) but in 
> my case on fedora 21 with 2.20-8 I get 0. My "failing" fedora 20 uses
> 2.18.
> 
> I don't know whether it's really a bug in glibc since Linux man pages do 
> allow ENOENT (and some other codes) to indicate absence of entry. (But 
> then if this is not a bug in glibc then there is a bug in man pages' 
> example code).
> 
> In any case, I think we need to account for this in libxl.

I'm not sure we do for an apparently transient issue in a fast moving
"bleeding edge" type distro, for a version of which is already (long, by
their standards) out of support.

Especially given the implication in the bug that it can be worked around by
frobbing with /etc/nsswitch.conf and the fact the distro is treating it as
a bug rather than as by design.

Lastly, even the Linux man pages only, to my reading, seem to countenance
ENOENT etc for getpwnam, not for getpwnam_r, the latter does have a well
defined indication of not found vs error.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel