Bug 1002782

Summary: 1.6.0-1 lightdm-gtk-greeter segfaults if session last used is uninstalled (and has a silly cache location)
Product: [Fedora] Fedora Reporter: Jack Perdue <ss>
Component: lightdm-gtkAssignee: Rex Dieter <rdieter>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: cwickert, dan.mashal, gregor, rdieter, rmilasan, ss
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: lightdm-gtk-1.6.1-2.fc20 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-10-18 19:30:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
lightdm-gtk-greeter-fix-segfault-when-last_session-is-invalid.patch none

Description Jack Perdue 2013-08-30 01:27:15 UTC
Description of problem:

When using lightdm-gtk-greeter, if, while no one is logged into the graphical console, you uninstall the windows manager (xfce4/gnome/cinnamon/etc.) that was last invoked by the greater, it goes into segfault loopy land.

And it caches such info in a silly place.


Version-Release number of selected component (if applicable):

lightdm-gtk-1.6.0-1.fc19.x86_64


How reproducible:

Hopefully "very" given the steps below.


Steps to Reproduce:

yum -y install xfce4-session lightdm-gtk
systemctl disable gdm # or whatever the current display manager is
systemctl enable lightdm  # use lightdm instead
reboot

# select xfce4 at the top right of the screen (they moved it in 1.6)
# login
# logout
# open up a TTY console (Ctrl-Alt-F2)
# login

yum -y remove xfce4-session
reboot

# watch as lightdm-gtk-greeter repeatedly falls all over itself


Actual results:

(snipped)
Aug 29 19:56:40 adrastea kernel: [12565.171691] lightdm-gtk-gre[10655]: segfault at 7fffd46ccff8 ip 00007fecf534e374 sp 00007fffd46ccff0 error 6 in libc-2.17.so[7fecf52d2000+1b6000]
Aug 29 19:56:41 adrastea kernel: [12567.074297] lightdm-gtk-gre[10680]: segfault at 7fff9a725ff8 ip 00007f36ed4eb374 sp 00007fff9a725ff0 error 6 in libc-2.17.so[7f36ed46f000+1b6000]
Aug 29 19:56:43 adrastea kernel: [12568.989247] lightdm-gtk-gre[10705]: segfault at 7fffeb483fb0 ip 00007f22bf26b363 sp 00007fffeb483fa0 error 6 in libc-2.17.so[7f22bf1ef000+1b6000]
Aug 29 19:56:45 adrastea kernel: [12570.905937] lightdm-gtk-gre[10730]: segfault at 7fff8aec8fb0 ip 00007f27be072363 sp 00007fff8aec8fa0 error 6 in libc-2.17.so[7f27bdff6000+1b6000]
Aug 29 19:56:47 adrastea kernel: [12572.835317] lightdm-gtk-gre[10755]: segfault at 7fffbf1affa0 ip 00007f63b07dc363 sp 00007fffbf1aff90 error 6 in libc-2.17.so[7f63b0760000+1b6000]
Aug 29 19:56:49 adrastea kernel: [12574.739749] lightdm-gtk-gre[10780]: segfault at 7fff61627fd0 ip 00007f34406c3363 sp 00007fff61627fc0 error 6 in libc-2.17.so[7f3440647000+1b6000]
(snipped)


Expected results:

The greeter starts so the computer is usable by the non-technical user.


Additional info:

The workaround is:

1) reinstall the last used windows manager, reboot, login using another manager, and the remove the one just reinstalled and then reboot 

2) delete the file /var/log/lightdm/.cache/lightdm-gtk-greeter/state (which is a silly place to cache state information)

The state file is simply this:

[greeter]
last-user=slick
last-session=xfce

While tracking this down I also saw mention that the same thing happens if you delete the last user that logged in, but I haven't tested that so am only reporting the last-session issue for now.

Comment 1 Jack Perdue 2013-08-30 01:57:37 UTC
Of course, you can replace both the "reboot"s in the steps to reproduce by entering the following in a TTY session:

telinit 3
telinit 5

which may or may not be faster depending upon how fast you type.

Comment 2 Robert Milasan 2013-10-08 12:01:59 UTC
Created attachment 809239 [details]
lightdm-gtk-greeter-fix-segfault-when-last_session-is-invalid.patch

Here is the fix for the last_session segfault issue.

Comment 3 Robert Milasan 2013-10-08 12:03:05 UTC
I've tested this in normal circumstances, and it works as expected. Please test if possible.

Comment 4 Jack Perdue 2013-10-08 16:01:46 UTC
Looks good here.  I rebuilt the RPM with included patch, telinit 3, yum install newrpm, telinit5, all is happy.  I then telinit 3, yum install oldrpm, telinit 5 and it goes back to segfault loopy land.  So that solves the segfault issue.  

The issue of being a stupid place to store a state file remains, but that can be dealt with later I guess (I'd think that /var/cache/lightdm/lightdm-gtk/state would be a preferable location if only because it isn't in a .hidden folder in the log directory but one thing at a time).

Thanks Robert.  Hopefully this can go to testing (or wherever it goes next).

Comment 5 Robert Milasan 2013-10-08 16:31:49 UTC
Jack, in openSUSE the state file is in: /var/lib/lightdm/.cache/lightdm-gtk-greeter/state, so I guess this can be tuned.

I'm happy that the patch works. This also works well in openSUSE, just to make it clear :)

Comment 6 Rex Dieter 2013-10-08 16:47:14 UTC
ah, lightd.conf lies!  it claims the default location is:

#cache-directory=/var/cache/lightdm

looks like we can fix at least 2 problems at once here. :)

Comment 7 Rex Dieter 2013-10-08 16:53:08 UTC
Oh geesh, so we run lightdm as lightdm user with passwd entry:

lightdm:x:992:990::/var/log/lightdm:/sbin/nologin

and these items use g_get_user_cache_dir calls, guess where those go? :-/

Comment 8 Rex Dieter 2013-10-08 16:56:57 UTC
In particular,

    /* If not running as root write output to directories we control */
    if (getuid () != 0)
    {
        g_free (default_log_dir);
        default_log_dir = g_build_filename (g_get_user_cache_dir (), "lightdm", "log", NULL);
        g_free (default_run_dir);
        default_run_dir = g_build_filename (g_get_user_cache_dir (), "lightdm", "run", NULL);
        g_free (default_cache_dir);
        default_cache_dir = g_build_filename (g_get_user_cache_dir (), "lightdm", "cache", NULL);
    }

ick, ick, ick.  Robert, do you know how opensuse handles this?  set a better lightdm homedir, or set these explicitly in lightdm.conf (or other)?

Comment 9 Robert Milasan 2013-10-08 17:06:35 UTC
Yep, it's based on /etc/passwd:

suse-machine:~ # cat /etc/passwd|grep light
lightdm:x:490:490:LightDM daemon:/var/lib/lightdm:/bin/false

:)

Well I guess one bug turned into two bugs.

Comment 10 Robert Milasan 2013-10-08 17:07:51 UTC
But does it work if cache-directory is set in lightdm.conf ? Meaning does it take the conf?

Comment 11 Rex Dieter 2013-10-08 19:08:57 UTC
Hrm, I thought it would, but explicitly adding to lightdm.conf:
log-directory=/var/log/lightdm
run-directory=/var/run/lightdm
cache-directory=/var/cache/lightdm

but the stuff under /var/log/lightdm/ still seems to get created and used. :(

Comment 12 Rex Dieter 2013-10-08 19:51:38 UTC
Sorry for my rambling, but ultimately it looks like that previous stuff is not used by lightdm-gtk-greeter :
 
    state_dir = g_build_filename (g_get_user_cache_dir (), "lightdm-gtk-greeter", NULL);
    g_mkdir_with_parents (state_dir, 0775);
    state_filename = g_build_filename (state_dir, "state", NULL);
    g_free (state_dir);

No idea why they chose to hard-code the use of g_get_user_cache_dir instead of grok'ing lightdm cache-directory key, but there you have it.

I'll change the default lightdm user home to be /var/lib/lightdm (instead of /var/log/lightdm), to be at least a little more sane (this will only affect new installs)

Comment 13 Fedora Update System 2013-10-08 20:56:02 UTC
lightdm-gtk-1.6.1-2.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/lightdm-gtk-1.6.1-2.fc20

Comment 14 Fedora Update System 2013-10-08 20:56:55 UTC
lightdm-gtk-1.6.1-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/lightdm-gtk-1.6.1-2.fc19

Comment 15 Fedora Update System 2013-10-09 14:53:33 UTC
Package lightdm-gtk-1.6.1-2.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing lightdm-gtk-1.6.1-2.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-18585/lightdm-gtk-1.6.1-2.fc20
then log in and leave karma (feedback).

Comment 16 Fedora Update System 2013-10-18 19:30:43 UTC
lightdm-gtk-1.6.1-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 17 Fedora Update System 2013-11-10 06:04:52 UTC
lightdm-gtk-1.6.1-2.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.