dm-tool lock + alt-ctrl-f7

[niknah]

Ubuntu 12.04.1
lightdm 1.2.1-0ubuntu1
lightdm-gtk-greeter 1.1.5-0ubuntu1

* Run...
dm-tool lock
Press alt-ctrl-f7

Now I'm back in without a password.

Same with switch-to-greeter

I don't know if it's supposed to be this way or it's a security problem.

[Marc Joliet (marcec)]

The dm-tool program that is part of x11-misc/lightdm apparently spawns a new lightdm process on every invocation of the "lock" command. On my system I found that after a while, "dm-tool lock" would merely switch to VT8 instead of switching to the lightdm greeter, leaving my session without password protection. There were many ligthdm subprocesses, all using lots of CPU (such that both cores were maxed out).

An example after one invocation of "dm-tool lock":

    % ps aux|grep lightdm
    root 7565 0.4 1.5 312044 62876 ? SLsl 12:07 0:00 /usr/sbin/lightdm
    root 7603 4.7 0.7 146248 31840 tty7 Ssl+ 12:07 0:01 /usr/bin/X :0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
    root 7958 0.1 0.1 208428 6280 ? Sl 12:07 0:00 lightdm --session-child 12 19
    root 13642 0.6 0.0 162380 3736 ? Sl 12:07 0:00 lightdm --session-child 19 26
    marcec 14742 0.0 0.0 14072 960 pts/3 S+ 12:07 0:00 grep lightd

There's the main lightdm process and *two* children, instead of the usual one.

The upstream bug at $URL mentions the same basic symptom I've seen (albeit for an older version of lightdm) and sadly hasn't had any activity.

Reproducible: Always

Steps to Reproduce:
1. invoke "dm-tool lock"
2. log back in
3. run "ps aux|grep lightdm"
4. repeat steps 1 and 2 several times (not sure how many)
Actual Results:
The ps output shows two lightdm subprocesses instead of the usual one, after step 4 lightdm stops locking and instead simply switches to another VT (in my case 8). It's possible to switch to the session via Alt-F7 (*no* password protection!).

Expected Results:
The ps output shows the main ligthdm process and one subprocess, step 4 should *always* properly lock the session.

% emerge --info lightdm
Portage 2.1.12.2 (default/linux/amd64/13.0, gcc-4.6.3, glibc-2.15-r3, 3.10.7-gentoo x86_64)
=================================================================
                         System Settings
=================================================================
System uname: Linux-3.10.7-gentoo-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_4200+-with-gentoo-2.2
KiB Mem: 4047292 total, 200908 free
KiB Swap: 4194300 total, 4175728 free
Timestamp of tree: Tue, 03 Sep 2013 20:45:01 +0000
ld GNU ld (GNU Binutils) 2.23.1
app-shells/bash: 4.2_p45
dev-lang/python: 2.7.5-r2, 3.2.5-r2
dev-util/cmake: 2.8.10.2-r2
dev-util/pkgconfig: 0.28
sys-apps/baselayout: 2.2
sys-apps/openrc: 0.11.8
sys-apps/sandbox: 2.6-r1
sys-devel/autoconf: 2.13, 2.69
sys-devel/automake: 1.11.6, 1.12.6, 1.13.4
sys-devel/binutils: 2.23.1
sys-devel/gcc: 4.6.3
sys-devel/gcc-config: 1.7.3
sys-devel/libtool: 2.4-r1
sys-devel/make: 3.82-r4
sys-kernel/linux-headers: 3.9 (virtual/os-headers)
sys-libs/glibc: 2.15-r3
Repositories: gentoo science wagnerflo sunrise overnight ladi proaudio pd-overlay mjoliet
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=native -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/co...

[Tomwij-1 (tomwij-1)]

Please don't manually CC maintainers.

[Marc Joliet (marcec)]

(In reply to Tom Wijsman (TomWij) from comment #1)
> Please don't manually CC maintainers.

OK, sorry about that.

[Markos Chandras (hwoarang)]

Ok thanks for the report. We will track the upstream bug.

[Marc Joliet (marcec)]

I got around to trying new versions of lightdm and found out that lightdm-1.7.16 does *not* show the bug. Neither "dm-tool lock" nor "dm-tool switch-to-greeter" exhibit the behaviour I described, lightdm-1.6.2 however still did. Therefore the yet-to-come stable series 1.8.x ought to be rid of this bug :) .

Perhaps somebody with a launchpad account can add a comment to this effect to the upstream bug?

(As an aside: lightdm >=1.6.2 (or maybe it was lightdm-gtk-greeter-1.6.0) fixed an issue where the greeter background was set to black instead of to the specified image on a borrowed laptop; in contrast, my desktop showed no problems in this regard.)

[Markos Chandras (hwoarang)]

Unfortunately I have not launchpad account. However, since this appears to be solved in the latest ~testing ebuild we can close this bug.

Thanks for the report and for testing.

[Marc Joliet (marcec)]

Hi, I just wanted to note that I see the same bug in Gentoo Linux.

I noticed that lightdm 1.7.16 does *not* exhibit this behaviour. Version 1.6.2 however still did (see the downstream bug). So maybe this bug has been fixed.

[Marc Joliet (marcec)]

(In reply to Markos Chandras from comment #5)
> Unfortunately I have not launchpad account. However, since this appears to
> be solved in the latest ~testing ebuild we can close this bug.
>
> Thanks for the report and for testing.

Gladly!

Just a FYI: I decided to just create a Launchpad account and have linked the upstream bug to this one and posted a comment there.

[Marc Joliet (marcec)]

Damn it, I spoke too soon.

As of yesterday, I've started seeing this bug again. I noticed it when the screen simply went black after calling "dm-tool lock". I was able to get to the desktop session via Alt-F7 as per the original bug description and sure enough, "ps aux" showed lots of ligthdm session children. After quitting my desktop session (well, window manager), ligthdm just quit (no SEGFAULT, or anything else in syslog, the process apparently just exited). So I was left to restart the xdm service.

After that, I verified that locking via dm-tool switches to a greeter on VT8, so that you can go back to the desktop session with a simple Alt-F7. That, again, shows new session children, but they disappeared after logging in again.

I'm perplexed, because I was certain that I didn't see this bug anymore after the upgrade in comment #4.

I'll attach the list of packages I've upgraded in case you can see anything that might be involved. I'll also attach a log file of me loggin in, locking, and unlocking the session.

[Marc Joliet (marcec)]

Created attachment 360572
Output of genlop -l --date 2013-09-26

This is the list of packages I upgraded/installed after comment #4.

[Marc Joliet (marcec)]

Created attachment 360574
The lightdm log

[Marc Joliet (marcec)]

Created attachment 360578
The lightdm-greeter log from VT7

[Marc Joliet (marcec)]

Created attachment 360580
The lightdm-greeter log from VT8

I don't think there's anything interesting in the greeter's logs, but thought I would put them here for completions sake. Also, .xsession-errors doesn't contain anything pertaining to lightdm.

[Yves-Alexis Perez (corsac)]

Doesn't the problem lie in the fact that the dbus lock signal is not blocking, and that there's no way for the one emitting the signal (beeing dm-tool lock or another tool) to be sure someone catched the signal and actually locked the screen?

[doak (doak)]

I sadly can not comment on corsac as I do not know the internals and have not found usefull information about that yet.
The behaviour is still the same (as of lightdm v1.12.1 on archlinux), at least considering switching back to not locked session at previous VT.

Archlinux Wiki contains some hint describing the use case of user switching (which seems to be a related issue) and links to light-locker package: https://wiki.archlinux.org/index.php/LightDM#User_switching_under_Xfce_4
Using this package can be a workaround I guess.

Anyway, I don't like trying out things in a security related issue!

[doak (doak)]

Perhaps this dbus issue is related: https://bugs.launchpad.net/lightdm/+bug/1308789

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[niknah (hankin0)]

The original report was for Ubuntu 12.04.
It's working in UIbuntu 14.04, lightdm 1.10.5

Thanks

[Jarno Suni (jarnos)]

The bug still occurs in Ubuntu 14.04, if light-locker is not enabled.

[Jarno Suni (jarnos)]

That is told in the duplicate bug report.

[Robert Ancell (robert-ancell)]

There is nothing LightDM can do to stop you switching VTs. It requests the session is locked using logind/ConsoleKit and then it's up to the session to lock itself.

[marcec (marcec-gentoo-bugs)]

The upstream bug was closed as invalid in 2016, with no activity since then (i.e., no more "me too!"s), and I had switched to KDE4 about two years before that, so haven't really cared about this bug in the last 6 years. Hence: Is this bug still reproducible, or can it be closed now? Because I don't know about you, but I'd be glad to get it off of my open bug list ;-) .

[marecki (marecki-gentoo-bugs)]

As far as I can tell this is MASSIVELY out of date. Definitely haven't ever seen this problem with 1.30.0, at least.