On Thu, Sep 13, 2001 at 03:33:02PM -0500, Steve Langasek wrote: > On Thu, 13 Sep 2001, Nalin Dahyabhai wrote: > > > It surprised me, too, but I couldn't find anything in the specifications > > that mentioned the value of the pointer when the call fails. But anyhow. > > At the very least, there's a bug in the glibc documentation for claiming that > the pointer /will/ be set to NULL. > > >> Seems to trade reentrancy problems in the system as a whole for reentrancy > >> problems within the modules. I'd rather that each function/module that's a > >> consumer of getpwnam_r() be expected to keep track of its own buffers and free > >> them when necessary. > > > I'd prefer just the opposite. Expecting each module to handle the ERANGE > > error independently is going to require large-scale changes, and I'd > > rather that the logic to do so be put in one place to avoid the need to > > change similar code in numerous places in the future if something is found > > to be incorrect in the implementation. > > But if we don't do this, we're no closer to having thread-safe modules, even > on systems that provide the necessary libc functions. I don't particularly > /like/ needing to maintain the code in a dozen places, but I don't see any > other way to solve this particular problem. I think Nalin was proposing to share a pw buf per-PAM handle. I don't think PAM should guarantee that more than one thread can access a given handle concurrently, though PAM (and the modules) ought to guarantee that multiple threads can use PAM concurrently (as long as each PAM handle is accessed serially). So what Nalin is proposing wouldn't hurt multi-threadedness of PAM/modules. But there must be a way to replace the pw buf when either: a) PAM_USER is changed, or b) the user's record has been updated. In any case, getpw*() suck and I'll repeat my mantra that we need a more extensible user profile interface than the old NSS getpw*/getsp*/getgr*() API family... (Yes, it must be getting boring -- no, I'm not implmenting any such thing). > Steve Langasek > postmodern programmer > Nico -- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
