[12] New NSS application functions
Florian Weimer
fweimer@redhat.com
Sat Sep 14 12:23:37 GMT 2024
* Replace getpwuid_r with something usable
* Maintaining library safety is crucial
- Thread-safe getpwuid would not achieve that
* Also provide duppwent and freepwent functions.
* Layered on top of new NSS modules (with backwards interoperability)
Currently, the NSS interfaces exposed to applications come in two
variants. There is one that uses an internal buffer (getpwuid), and one
that uses a caller-supplied buffer (getpwuid_r). The former is not
thread-safe in the current glibc implementation, the latter is
cumbersome to use (you must write a retry loop that increases the buffer
size on ERANGE errors).
I originally explored making the getpwuid function variants thread-safe,
which is very likely possible without impacting
backwards-compatibility. But I then realized that this still wouldn't be
library-safe (a term coined by Rich Felker): The application may keep
around a struct passwd returned from a getpwuid call, call a separately
developed library functions which happens to call getpwuid internally
(maybe for constructing a log message). Even if thread-safe, this still
clobbers the previous getpwuid, and if the application keeps using its
previously stored struct passwd pointer, we have undefined behavior.
Nowadays, I lean towards creating new lookup functions (getpwuid2) which
allocate the buffer internally, returns that to the application (without
storing it in thread-local storage) and the caller has to call a
function to free that pointer after it's done with it (say freepwent, to
follow the existing getpwent naming convention). We can also add a
duppwent function, to make it easy to allocate struct passwd objects in
a way that is compatible with freepwent. The getpwent/endpwent
iterators would benefit from an overhaul, too, to make the iterator
explicit (instead of implying a global one).
This complements the internal buffer management changes from the New NSS
module API project. It's a large project because of the number of
interfaces involved. The duppwent/freepwent functions would help with
implementing the new allocating NSS module interfaces, though.
More information about the Libc-alpha
mailing list