how is pulseaudio supposed to work?

[Patrice Dumas]

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