Yes, if KRB5CCNAME were set in the environment of the screen saver, it
would fix this problem.
To be clear, this isn't a bug in libpam-krb5, but in the means by which
the screen saver is launched without the user's environment set properly
(which should be created via the pam_setcred and
On Debian/Stretch - lightdm 1.18.3 - this issue is still present.
The script mentioned in comment 9 has served us well for the past 3+
years and is "maintained" on https://github.com/cedric-dufour/custom-
conf/tree/master/generic/all/custom-conf-pam-krb5/usr/share/custom-conf-
FWIW, this issue is also present using gdm3 in Ubuntu 16.04. With
pam_krb5's debug option set, I see the following during initial login
(with successful credential cache construction):
gdm-password]: pam_krb5(gdm-password:auth): pam_sm_authenticate: entry
gdm-password]:
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: libpam-krb5 (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to lightdm in Ubuntu.
Hello,
Has any progress been made with this issue?
Is there any workaround to circumvent it?
Thanks for the feedback and best
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to lightdm in Ubuntu.
https://bugs.launchpad.net/bugs/1336663
I'm not aware of any activity on this since Robert Ancell's comment #4
indicating that a proper fix might require extensive refactoring (too
extensive for Ubuntu T?). As a workaround I've added an Upstart
configuration file to run krenew in every user's session; it's as simple
as
start on
Hello again,
Thanks @Sergio for the krenew tip.
I'd rather not automatically renew a user ticket without having him
supply its password from time to time.
I came up with a *horrible* workaround which I believe does not break
the entire Kerberos security (please correct me if I'm wrong):
In
* Robert Ancell [2014-07-08 04:27:34 -]:
It's not clear if the problem is the way we are using PAM in LightDM
(i.e. insufficient/wrong information for pam-krb5 to do the right thing)
or an assumption by pam-krb5 that is not occurring.
pam_krb5 needs to be told the name of the credentials
Yes. This bug probably means that lightdm is not associating the login
session's environment with the pam handle for the unlock action. It
looks like lightdm correctly copies the contents of the pam env
(pam_getenvlist) to the session environment (judging by the $KRB5CCNAME
that I have in my
We do have the PAM handle open but it's in a subprocess that the daemon
has no communication with. It was my assumption (fear) that we might
need to access it for credential refreshing. This will take quite some
refactoring to make this work but should be possible.
--
You received this bug
Note that all that pam-krb5 specifically cares about is KRB5CCNAME, so
an alternative approach that may require less refactoring and would work
for that PAM module would be to preserve the PAM environment from
pam_getenvlist and set those variables in the environment before
invoking PAM for
** Also affects: lightdm
Importance: Undecided
Status: New
** Changed in: lightdm
Importance: Undecided = Medium
** Changed in: lightdm (Ubuntu)
Importance: Undecided = Medium
** Changed in: lightdm
Status: New = Triaged
** Changed in: lightdm (Ubuntu)
Status: New
This bug occurs when when using LightDM as a lockscreen and pam-krb5 not
correctly updating the credentials of the session you switch back to.
It's not clear if the problem is the way we are using PAM in LightDM
(i.e. insufficient/wrong information for pam-krb5 to do the right thing)
or an
13 matches
Mail list logo
