how is pulseaudio supposed to work?

Nalin Dahyabhai nalin at redhat.com
Wed Dec 19 17:10:26 UTC 2007


On Wed, Dec 19, 2007 at 05:42:40PM +0100, Patrice Dumas wrote:
> 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...).

That means you can probably assume you're running as root, but I don't
see that it simplifies the problem beyond that.

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

I couldn't say.  Maybe.  Lennart's going to know more about that than I
do, I think.

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

I'm not sure I understand what you're saying here.  I think you're
suggesting that for the subset of PAM-aware applications which log a
user in, that we can assume some specifics about the execution
environment, and I'd disagree with that.

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

In this case?  I don't know -- if something breaks now, I'm not the
person who gets asked to fix it.  I used to be, and to put it bluntly,
it sucked.

And I'll freely admit that it's colored my perception.

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

It may be better in terms of configurability, but I don't think it's the
right place to do it.  I'm not against some other means of doing exactly
that (and I think we both agree that we'd like *something* like that),
but I think that PAM is an unsafe place to do it.

Cheers,

Nalin




More information about the fedora-devel-list mailing list