mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Conway <neil.con...@gmail.com>
Subject Re: Review Request 54952: Made `getpwnam_r` error handling more robust.
Date Wed, 28 Dec 2016 21:26:03 GMT


> On Dec. 23, 2016, 11:08 a.m., Benjamin Bannier wrote:
> > 3rdparty/stout/include/stout/os/posix/su.hpp, line 58
> > <https://reviews.apache.org/r/54952/diff/2/?file=1591277#file1591277line58>
> >
> >     We'll check `result != nullptr` later; could you initialize it here for robustness?

I don't think this is an improvement, because it obscures the fact that (a) `result` is only
accessed _after_ `getpwnam_r` is called, and (b) `getpwnam_r` always writes-through to the
`result` pointer. Leaving the variable uninitialized lets the compiler warn us if the code
is changed to violate these properties.


> On Dec. 23, 2016, 11:08 a.m., Benjamin Bannier wrote:
> > 3rdparty/stout/include/stout/os/posix/su.hpp, line 104
> > <https://reviews.apache.org/r/54952/diff/2/?file=1591277#file1591277line104>
> >
> >     Checking for `__linux__` here seems wrong as we care about a feature of the
used C stdlib, not the platform.
> >     
> >     If I understand this code and the comment above it correctly, we should never
enter this `if` branch with a POSIX-conformant stdlib, but could potentially if e.g., glibc
is being used.
> >     
> >     We should either fix this to (a) use the correct feature check macro checking
for the used C stdlib instead of the platform, or since taking this branch is impossible with
a POSIX-conformant stdlib, (b) just unconditionally enable this sanity check (i.e., drop the
`ifdef`). I lean towards the second option as it would add robustness to this wrapper to deal
with other non-conformant stdlibs.

Fair point. I'd lean towards dropping the `ifdef` is probably better as well.


- Neil


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/54952/#review160066
-----------------------------------------------------------


On Dec. 22, 2016, 8:50 p.m., Neil Conway wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/54952/
> -----------------------------------------------------------
> 
> (Updated Dec. 22, 2016, 8:50 p.m.)
> 
> 
> Review request for mesos and Alexander Rukletsov.
> 
> 
> Bugs: MESOS-6826
>     https://issues.apache.org/jira/browse/MESOS-6826
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> According to POSIX, `getpwnam_r` returns 0 (and sets `result` to the
> null pointer) when the specified user name is not found. However,
> certain versions of Linux (e.g., RHEL7, recent Arch Linux) return
> non-zero and set `errno` (to one of several different values) when
> `getpwnam_r` is passed an invalid user name.
> 
> In stout, we want to treat the "invalid user name" and "user name not
> found" cases the same. Both the POSIX spec and Linux manpages call out
> certain errno values as definitely indicating errors (e.g., EIO,
> EMFILE). On Linux, we check `errno` and return an error to the caller if
> `errno` appears in that list. We treat `errno` values not in that list
> as equivalent to "user not found".
> 
> On other (Unix) platforms, we treat any non-zero return value from
> `getpwnam_r` as indicating an error.
> 
> 
> Diffs
> -----
> 
>   3rdparty/stout/include/stout/os/posix/su.hpp f3f45ebf006f0f8e7e70b0f4c4ed76465530c58e

>   3rdparty/stout/tests/os_tests.cpp 8d2005b1f109b4025aa8368600763db9c829d0c5 
> 
> Diff: https://reviews.apache.org/r/54952/diff/
> 
> 
> Testing
> -------
> 
> `make check` on Arch Linux. `OsTest.User` fails without this patch but succeeds with
this patch.
> 
> 
> Thanks,
> 
> Neil Conway
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message