light-locker appears to incorrectly handle Kerberos ticket cache filenames
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
lightdm (Ubuntu) |
Confirmed
|
Medium
|
Unassigned |
Bug Description
When unlocking an Ubuntu 16.04 system which is using light-locker as the screen saver, Kerberos authentication works for a normal, unprivileged user, except that the resulting ticket cache is incorrectly named. Instead of the resulting ticket cache created as a result of such successful authentication being named something like:
krb5cc_1000 (if the UID of the user is 1000)
...the cache file is named:
krb5cc_0 (which would presumably be correct if root were logging in, but not a normal, unprivileged user)
I am willing to help debug this issue, so if there is anything you would like me to try, please let me know.
Thanks,
Brian
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: light-locker 1.7.0-2ubuntu1
ProcVersionSign
Uname: Linux 4.4.0-14-generic x86_64
ApportVersion: 2.20-0ubuntu3
Architecture: amd64
Date: Sat Mar 19 22:32:52 2016
InstallationDate: Installed on 2016-03-19 (0 days ago)
InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160318)
ProcEnviron:
TERM=xterm-
PATH=(custom, no user)
XDG_RUNTIME_
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: light-locker
UpgradeStatus: No upgrade log present (probably fresh install)
Changed in light-locker (Ubuntu): | |
importance: | Undecided → Medium |
I should also add, for clarification to anyone possibly unfamiliar with Kerberos and, therefore, the impact of this bug, that the result of this bug is that the incorrectly-named ticket cache is not visible to applications searching for the ticket cache for the user, so the user cannot (without taking unusual measures) use the resulting ticket cache. The ticket cache is correctly owned by the user, but the ticket cache is not found because the filename is incorrect. As a result, the user would normally need to acquire new Kerberos tickets post-login, which would be unnecessary if this issue were corrected.
I will also add that using "xscreensaver" instead of light-locker is a workaround, but of course results in perhaps a less-consistent experience for the user.
Thanks,
Brian