Stopping and starting the session dbusdaemon with PAM.

[Stef Bon]

On Friday 21 October 2005 20:51, you wrote:
> Speaking to a couple of people around here I got the impression that
> this is not the best option.   Nalin's response came down to these
> arguments:
>
> * Privilege level
>   Is the app running as root or not?  If you're a session module, can
>   you make the right thing happen for both cases?

pam-script has the ability to run as root, or as the user who's logging in. Al 
the scripts can run as root or a normal other user. At this moment I use the 
option runas=root for the sessionscripts. 
When running as root, all my scripts use sudo to change to the user logging in 
to execute commands where possible.
I'm working on it so this option runas=root is not neccasary anymore. Running 
as root can lead to problems I know.

> * Signal handling -- are there handlers for signals (such as SIGCHLD)
>   installed which will keep you from reaping your child process?

Yes, pam_script has handlers for signals.

> * Threads (less likely for PAM, commonplace for nsswitch)
>   Are you creating state that will exist after you return control of
>   execution to the application?  Will things work correctly if the
>   calling application spawns another thread, or forks a second copy of
>   itself?

I can't say. Haven't tested this. I see that there is a potential problem.

>
> He also though that pam shouldn't be abused for anything not dealing
> with authentication.

I do not agree. The open_session and close_session calls are for preparing and 
closing a session for a user. PAM is THE place to open and close sessions, 
and I think starting scripts to launch the dbus daemon for example is a good 
thing.

>
> Steve Grubb, one of our security experts basically reiterated the first
> argument.  If you get executed as root then the session daemon has the
> potential to do bad things.

See above.

>
> Ray Strode who worked on a couple of environment variable issues said
> you lose out on propagating certain environment variables if you start
> the bus too early.  This means for example activated apps might not work
> properly.

Yes, but the environmentvariables are not set when a session opens in PAM, but 
these variables are stored in the ~/.profile.d/dbus.sh, which will be sourced 
when bash starts (by ~/.bash_profile). Look at the example on my page:

linux.bononline.nl

I'm proposing a change in ~/.bash_profile, which will source all the *.sh 
files in the ~/.profile.d dirctory. 

Stef Bon