Re: how is pulseaudio supposed to work?

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

 



On Wed, Dec 19, 2007 at 04:37:27PM +0100, Lennart Poettering wrote:
> 
> PAM is about authentication. It's just not the place to start
> daemons. I mean, why should we start it there? We don't start dbus from
> there either, or X11, or nm-applet, or gnome-volume-manager or
> seahorse-agent or gnome-screensaver or vino-server or anything else
> that runs in the usual login session.

Except for dbus, all the examples you cite are display specific stuff
that should not be started from pam anyway (they could but there is no
much point). A relevant case you could have done is starting ssh-agent.
It is indeed not display specific and it is done in the session script.
But there is also a pam module pam_ssh that can launch ssh-agent in the
pam session phase.

> And why don't we start those things from PAM? Because we already start
> them from the session manager, in the appropriate order. Because

All the login paths don't have a session manager.

PAM start things in the appropriate order, that is in the order they
appear on the session stack.

> starting and monitoring processes is just what a session manager is
> good in. A session manager is not good for authenticating users, and
> PAM is not great for starting/monitoring/stopping processes. So we

PAM is great for starting (and maybe stopping) session-wide processes.

> leave PAM the authentication and session preparation stuff, and leave
> session management to the session manager. 

PAM can also be used for session stuff.

> Also, PAM is system configuration. If we'd start PA from there, then
> the user would have no way to disable PA unless he's root. And, as it
> seems, some people are very eager to do just that. ;-)

Being able to have a policy to start PA set up by the administrator is
something that is interesting. Now it is optional, of course, not all
administrator would want to impose that, still something nice to have.
It would really simplify the PA support in anything else than gdm, and
allow for local administrator customization.

Of course, the priority of such stuff could be low, but, in my opinion,
not considering it is not nice to those who like to administer login and
session stuff through pam.

--
Pat

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux