Ctrl+Alt+F7 bypasses the light-locker lock-screen under XFCE

[Martin Meredith]

HOW TO REPRODUCE:
1. Create an user account with password.
2. Login in the new account using the XFCE desktop environment.
3. Lock the screen.
4. Hit the Ctrl+Alt+F7 key combination.

EXPECTED BEHAVIOUR:
- The user session to be unavailable due to no password being entered.

REAL BEHAVIOUR:
- The session is accessible without entering its password, due to the VT8 being bypassed to the original VT using the Ctrl+Alt+F7 key combination.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: light-locker 1.4.0-0ubuntu1
ProcVersionSignature: Ubuntu 3.13.0-43.72-generic 3.13.11.11
Uname: Linux 3.13.0-43-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.6
Architecture: amd64
CurrentDesktop: XFCE
Date: Tue Jan 13 10:34:10 2015
InstallationDate: Installed on 2015-01-06 (6 days ago)
InstallationMedia: Xubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.2)
ProcEnviron:
 LANGUAGE=en_GB:en
 PATH=(custom, no user)
 LANG=en_GB.UTF-8
 SHELL=/bin/zsh
SourcePackage: light-locker
UpgradeStatus: No upgrade log present (probably fresh install)

[Martin Meredith (mez)]

Alex Denvir subscribed, as he's the one who bought this to my attention.

[Simon Steinbeiß (ochosi)]

With light-locker running, you can switch back to VT7, but it will block your access to the running session there and automatically redirect you to VT8.

So yeah, going to a new VT is expected and part of the plan. If you don't have light-locker running, then of course this will be a problem, because your session will be unlocked and unprotected (as with any other screenlocker, it only works when installed ;)).

[Martin Meredith (mez)]

Hi Simon,

Unfortunately, this isn't happening. I'm able to switch to VT7 and use the machine. (my access is not blocked to the running session)

[Martin Meredith (mez)]

(I'm currently setting up a VM to test this on, but, If need be, I'll film what's happening and upload that :))

[Martin Meredith (mez)]

Changing to incomplete, as I can confirm that this is happening. Invalid would mean I'm wrong. As I can provide documentary evidence regarding this, I'll mark it as complete until I do so :)

[Simon Steinbeiß (ochosi)]

As you might have noticed, I only marked it as invalid against xubuntu-meta, as it is not a bug in that component.

[Martin Meredith (mez)]

This issue is caused by Polkit not correctly working when box is installed as an LDAP client.

[Alberto Salvia Novella (es20490446e)]

Please:
- Report to <http://www.openldap.org/its/>.
- Paste the new report URL here.
- Set this bug status back to confirmed.

Thank you.

[Alberto Salvia Novella (es20490446e)]

Please, also repeat the above with <https://bugs.freedesktop.org/> against PolicyKit.

[Martin Meredith (mez)]

When combined with pam_ldap, to login to a centralised server, the GUI components of policykit fail, this means that the UI cannot shutdown, cannot mount disks, install packages, etc (Xubuntu 14.04).

I can provide any further info, but I don't know what you require to research this issue :).

pkexec from a terminal works fine.

[Martin Meredith (mez)]

Can;t seem to link the openldap bug, so

http://www.openldap.org/its/index.cgi/Incoming?id=8025

[Howard Chu (hyc)]

As I noted in our ITS#8025, this has nothing to do with upstream OpenLDAP. It may be specific to the particular way you built OpenLDAP in your distro, or it may be due to pam_ldap itself, but neither of these are in the purview of the OpenLDAP Project. Certainly there is nothing in vanilla OpenLDAP source code that operates at a low enough system level to interfere with screen blanking or locking.

[Martin Meredith (mez)]

Howard, It's having the usernames come from ldap, rather than the local system, that causes policykit to have weird stuff happen, that causes screen locking. It's all interconnected :)

The bug isn't in the parts individually, but in the integration of them all.

[Howard Chu (hyc)]

Try replacing pam-ldap/nss-ldap with nslcd and/or nssov and see if the problem persists. I'd bet it doesn't. See here https://bugs.launchpad.net/debian/+source/sudo/+bug/423252/comments/84 for reasons why you should have abandoned pam-ldap/nss-ldap years ago.

[Martin Meredith (mez)]

This has been tracked down to being an issue with libpam-ldap

[Martin Meredith (mez)]

Switching to libpam-ldapd and nslcd have fixed this issue. I've marked this as an issue against libpam-ldap.

[Martin Meredith (mez)]

https://github.com/opscode-cookbooks/openldap/issues/44 <-- this has been filed, as this is why we ended up with the outdated package

[Ryan Tandy (rtandy)]

Might be related to bug 781737. pam-ldap/nss-ldap dropping privileges is, AFAIK, caused by libgcrypt (bug 423252). If this is the same bug, then the pending openldap merge (bug 1395098) will resolve it, as gcrypt will no longer be used. But switching to nss-pam-ldapd is a good recommendation anyway, since the older modules are dead upstream.

[Nathan Stratton Treadway (nathanst)]

On Fri, Jan 16, 2015 at 18:05:04 -0000, Ryan Tandy wrote:
> will no longer be used. But switching to nss-pam-ldapd is a good
> recommendation anyway, since the older modules are dead upstream.

(In fact there is discussion underway regarding downgrading libnss-ldap
and libpam-ldap out of main; see LP: #1408478 for more information.)

      Nathan