----- 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: gnome-screensaver,
> > > 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 Gnome
> > 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 related
> 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
* sshd
Default = NetworkLogonRight
* ftp, samba
Default = BatchLogonRight
* crond
Regards,
Yassir.