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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Boris Ostrovsky writes ("[PATCH] libxl: Be more careful with error handling in 
libxl__dm_runas_helper()"):
> getpwnam_r() has fairly complicated return rules. From man pages:
> 
>   RETURN VALUE
>       ...
>       On success, getpwnam_r() and getpwuid_r() return zero, and set
>       *result to pwd.  If no matching  password record was found, these
>       functions return 0 and store NULL in *result. In case of error,
>       an error number is returned, and NULL is stored in *result.

I can't see anything in the SuS docs (which Ian C referred to) saying
that *result is updated even on error.  So I think you need to check
the return value first, and only then *result.

>   ERRORS
>       0 or ENOENT or ESRCH or EBADF or EPERM or ...
>             The given name or uid was not found.
> 
> While it's not clear what ellipses are meant to be, the way we currently
> treat return values from getpwnam_r() is no sufficient. In fact, two of
> my systems behave differently when username is not found: one returns
> ENOENT and the other returns 0. Both set *result to NULL.

I don't know where all that stuff about ENOENT comes from.  I'm
tempted to say this is a bug in your C library.  But I don't mind
treating ENOENT or ESRCH as ERROR_NOTFOUND.

I do mind treating EBADF or EPERM that way.

> While at it, also make sure we don't get stuck on ERANGE.

If you are going to do anything to this, you should use an
exponentially increasing buffer size.  Bear in mind that getpwnam_r is
already inside the trust boundary.

Thanks,
Ian.

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