[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [mituc@iasi.rdsnet.ro: pam limits drops privileges]

> > 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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []