----- Original Message -----
> On Thu, Jul 31, 2014 at 01:58:06PM -0400, Yassir Elley wrote:
> > ----- Original Message -----
> > > On Thu, Jul 03, 2014 at 01:39:38AM -0400, Yassir Elley wrote:
> > > >
> > > >
> > > > ----- Original Message -----
> > > > 4. Should we add the various gdm-* service names as interactive:
> > > > gdm-autologin, gdm-fingerprint, gdm-launch-environment, gdm-pin,
> > > > gdm-smartcard
> > > >
> > > > 5. Should we add the screen savers as interactive:
> > > > kscreensaver
> > >
> > > I think we should check with Ray Strode (halfline on
> > > IRC) about the and screensaver semantics. For instance in
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1104756#c16
Ray argued that
> > > screensaver only 're-authenticates'.
> > >
> > > I tend to agree about the gdm-* services, but again, checking with Ray
> > > might be a good idea. I think at least in the past, gdm would do some
> > > funky stuff with non-password authentication, like sending the authtoks
> > > to several different pam services and checking which ones would let the
> > > user through..I'm not sure if it's still the case now after the
> > > 3.x rewrite.
> > >
> > > What does gdm-launch-environment do?
> > >
> > I chatted with Ray Strode, who said we should provide defaults (of
> > interactive) for gdm-password, gdm-smartcard, and gdm-fingerprint. The pam
> > gnome-screensaver service has apparently been replaced with a gnome-shell
> > lock screen (starting with RHEL 7). Even on RHEL 6, while the
> > pam_acct_mgmt call is made when unlocking the gnome-screensaver, the
> > results are apparently ignored (b/c the user already has a running
> > session; the lock simply hides the gnome-shell display).
> Right, I found this out as well, it was a bit suprising to me, but meh,
> the user's TGT would expire anyway..
> > He didn't think default values were needed for any of the other gdm
> > services, such as:
> > * gdm-pin (no longer supported)
> > * gdm-autologin (password-less login)
> > * gdm-launch-environment (used to launch system session for gdm user to run
> > login process)
> > Note that there is no pam service simply named "gdm".
> > On the other side, there seem to be four pam services related to kdm: kdm,
> > kdm-np, kcheckpass, and kscreensaver. We should definitely include a
> > default for kdm, but we probably don't care about kdm-np (no-password).
> > Does anyone know how kscreensaver differs from kcheckpass (both have
> > identical pam files, which essentially include system-auth for all calls
> > (auth, account, session, password). Perhaps we should add defaults for
> > both kcheckpass and kscreensaver.
> I'm sorry, I have no idea about KDE at all...I know that ltinkl(a)r.c does a
> bit of KDE development, maybe he would get an idea.
Couldn't get in touch with ltinkl, but halfline pointed me to dvratil, who I chatted
with instead. When a user tries to unlock the screen, kscreenlocker_greet calls
kcheckpass, which calls pam_authenticate (but not pam_acct_mgmt). Also, kscreensaver is
apparently legacy. So, among the KDE pam services, I think we should only provide a
default for "kdm".
Here is a summary of the pam service names for which I am planning on providing default
logon rights (which can, of course, be overridden by configuration).
Default = InteractiveLogonRight
* login, su, su-l, sudo, sudo-i, gdm-password, gdm-fingerprint, gdm-smartcard, kdm
Default = RemoteInteractiveLogonRight
Default = NetworkLogonRight
* ftp, samba
Default = BatchLogonRight
We had a long and useful conversation about this topic on #sssd with
one of our users -- I'm adding him to the CC list so we can continue the