> > 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. This is no differant than file locking issues. It's not a pretty solution, but this is currently the only solution. This shouldn't be a PAM_ITEM. I'll propose an alternate solution. We could create a new library (say, libpam_util) that is distributed with Linux-PAM and is available for modules to link against. Such a library would contain system-dependent functions to provide certain capabilities in a uniform manor across all pam-compatible systems. List of such functions: file locking - a lckpwdf-type function that uses the "accepted" method on whatever system libpam_util was built on. So on glibc systems (and several proprietary systems), this would simply call lckpwdf(3), but on some other systems a more complicated scheme might be required. getpwnam & getspnam front-ends - some kind of scheme that could be adapted on all systems that would use getpwnam(3) in a thread-safe manor, be it getpwnam_r or a mutex to ensure only 1 call is made at a time. This would also need to return a pointer to memory that won't be overwritten during the next call. This will probably be from malloc(3), and thus there would need to be a function to free the memory used by the structures returned by each front-end. logging - not every system has syslog(3) Any other system-dependent thing that anybody can think of that is being used in multiple modules or applications. Perhaps a random data generator. I don't want to undertake such a project. I have no need for such a library, but I know that other people do. It would certainly make many of the pam modules "safe" on a large number of platforms. > 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). Regarding this, if such a libpam_util library was created, making the move from nss to "nnss" (from previous discussions) would be much easier since modules wouldn't need to be modified. - Adam Slattery
