[LightDM] pam usage

[Steve Grubb]

Hello,

While working on the audit patch for lightdm, I found out that for every 
login, it runs exactly 2 pam sessions back to back. No other login program 
does this. I showed this to an upstream pam maintainer and he was also 
puzzled. With the audit patch applied, I see the following:

# ausearch --start 10:30 -x lightdm --raw -m user_start | aureport --summary 
--pid

Pid Summary Report
==========================
total  pid
==========================
1  8939
1  8971

The first session shows this:

# ausearch --start 10:30 -p 8939 --raw | aureport --summary --event -i

Event Summary Report
======================
total  type
======================
1  CRED_ACQ
1  CRED_DISP
1  USER_START
1  USER_END
1  USER_LOGIN

And the second this:

[root at x2 ~]# ausearch --start 10:30 -p 8971 --raw | aureport --summary --event 
-i

Event Summary Report
======================
total  type
======================
1  LOGIN
1  USER_AUTH
1  USER_ACCT
1  CRED_ACQ
1  USER_START
1  USER_LOGIN
1  USER_ROLE_CHANGE

The first session is the odd one because its missing several events. Zeroing in 
on that one:

# ausearch --start 10:30 -p 8939 -i -m USER_START
----
type=USER_START msg=audit(12/03/2015 10:34:39.814:649) : pid=8939 uid=root 
auid=unset ses=unset subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 
msg='op=PAM:session_open grantors=pam_unix,pam_systemd acct=lightdm 
exe=/usr/sbin/lightdm hostname=? addr=? terminal=:0 res=success' 

What I found was that lightdm-greeter is running a pam session that appears to 
be for the sole purpose of calling pam_systemd.  In checking to see what all 
uses pam_systemd, I found that its normally called in system-auth which the 
regular lightdm calls. This is how all the other system entry points start the 
user session.

So, I was curious, what's the story behind the lightdm-greeter pam setup? Can 
llightdm be reworked to not need to run pam in the greeter? In reading the 
pam_systemd man page, it also says that it sets the $XDG_SESSION_ID variable 
which is based on the kernel assigned credentials set by pam_loginuid which is 
only run in the second session. (See the LOGIN event in the above reports.) It 
falls back to tracking a session another way, but it prefers being called 
after pam_loginuid. It seems like something is odd here.

Thanks,
-Steve