On Wed, Dec 19, 2007 at 11:16:41AM -0500, Nalin Dahyabhai wrote:
I recommend against using PAM as a place to be launching arbitrary
processes. The environment in which a module runs is just way too
underspecified to be dependable for doing that.
It is not arbitrary processes, and it is not relevant for all pam
modules, only for those that corresponds with login (like login, gdm,
wdm, ssh...).
Environment, privilege level, signal handling, none of it's
guaranteed
by the specification [1]. If you fork a process (from a module, which
Is it an issue for PA?
Also pam_ssh just does that and I don't know about any issue with
pam_ssh (well, any issue related with strating ssh-agent and setting the
environement variables).
is loaded by a shared library, with the calling application having
no
idea of what to expect), you have to be _very_ careful about how you do
it, and how you handle its termination, and how all of that interacts
with what the calling appliction's already doing.
In this case it is only for logins, not a module to be used from a
random application (or at the own administrator risk).
Even for the modules which are careful about this, we still run into
bugs. And many modules aren't careful.
We can assume that we are careful, can't we?
Sure, maybe we need something that'll serve the function of
launching
random stuff for you when you log in, but I don't think that PAM is it.
Nobody thinks that. But PAM allows to run some login wide stuff, with
modularity and under administrator control, and hook in any login
program. This may not be the perfect place to start PA, but it is still
better than starting it only in gdm. Maybe the X session script is
better, but the issue with session script (in
/etc/X11/xinit/xinitrc-common) is that it is only for X, and it is not
modular. The interest of pam is that the administrator may decide which
login path uses it.
--
Pat