lightdm ignores session selection of ldap users

[Ivo Maintz]

lightdm (and gdm too) ignores the session selection of ldap users on the first login after booting the pc. Instead of starting gnome-shell (for instance), the default session unitiy is started.
After a logout end re-login again, gnome-shell works. But the reboot of the pc results in ignoring user selections again. Furthermore, no ldap user is listed by lightdm after a fresh start.

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=11.10
DISTRIB_CODENAME=oneiric
DISTRIB_DESCRIPTION="Ubuntu 11.10"

Linux l3000 3.0.0-13-generic #22-Ubuntu SMP Wed Nov 2 13:27:26 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

This behavior appears on different machines, after a fresh install and also after upgrading from natty.

accountsservice 0.6.14-1github1ubuntu1
lightdm 1.0.6-0ubuntu1.1
gdm 3.0.4-0ubuntu11

[Karel (karel-redhat-bugs)]

Description of problem:

GDM ignores user's default session, it is always set to GNOME no matter what content is stored ~/.dmrc.

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

gdm-2.30.2-1.fc13.x86_64.rpm,

How reproducible:

Always.

Steps to Reproduce:
1. Install other windows manager (I tried with xmonad and awesome), or simply create *.session representing raw X session.
2. Login to the newly created session using GDM
3. Log out

Actual results:

After logging out from Awesome the Awesome session should be selected as default, but GNOME is selected as default session although the Awesome is shown as default session in ~/.dmrc.

Expected results:

After logging out from Awesome window manager is selected as user's default session.

Additional info:

This works on Fedora 12, with gdm-2.28.2.3.fc12, so it must be a regression.

I'm using custom gnome-session configuration which launches special Gnome session where Awesome replaces panel and window manager, however the issue occurs even if Awesome is run in the standalone mode or an raw Xsession is launched.

[Tajidin (tajidin-redhat-bugs)]

This bug has been triaged

--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

[Andrew (andrew-redhat-bugs)]

I have run across this problem, too, on Fedora 14.

[Andrew (andrew-redhat-bugs)]

I have confirmed that this is still a problem in Fedora 15.

[Ray (ray-redhat-bugs)]

we don't look at ~/.dmrc . GDM now uses the account service to choose default session.

Is

/var/lib/AccountsService/users

getting updated after you choose your session and log in?

[Andrew (andrew-redhat-bugs)]

After logging in once, GDM "remembers" the session. Unfortunately, if you log in on a different machine in a computer lab or reinstall, it "forgets" the session again. I understand that GDM can't (and shouldn't) write to users' home directories, but it should at least be reading the file in the home directories and honoring their explicit configuration.

[Fedora (fedora-redhat-bugs)]

This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.

[Elliott (elliott-redhat-bugs)]

I agree that it would be very nice to be able to specify this from a user's home directory. We have many Fedora machines in lab settings with NFS shared home directories. As it currently is, our only option is to have users select their default session each time they log into a different machine or else set up an NFS share just for /var/lib/AccountService/users.

[Ian (ian-redhat-bugs)]

I had to switch to kdm due to this problem on FC14 where gdm intermittently
forgot the session type. Under FC15 gdm seems to always use gnome by
default regardless of previous use. Can't see any selinux denies related
to this.

Switching to kdm on FC15 pays again; it just works.

I agree with Elliot; the setting must come from the user's home directory
not some local area elsewhere, otherwise our call center staff will go nuts
when they login on a different PC.

[Ian (ian-redhat-bugs)]

Here's a really horrid hack to make it ignore the default selection of GNOME on F15 and use user-script instead. Ensure your bash scripts place $HOME/bin in your PATH, then

ln -s /usr/libexec/xinit-compat $HOME/bin/gnome-session

[Konstantin (konstantin-redhat-bugs)]

Fedora 16, gdm 1:3.2.1.1-8.fc16
When logging in as a user who isn't listed (e.g. user ID below 1000), ~/.dmrc is not used - instead, the system defaults to gnome 3

[Konstantin (konstantin-redhat-bugs)]

Actually, nevermind. I'll just use LXDM from now on

[Launchpad Janitor (janitor)]

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

[Caleb Callaway (enlightened-despot)]

Just a note that the 'no LDAP user is listed after reboot' is likely the same bug reported in bug #873784 (https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/873784)

[Caleb Callaway (enlightened-despot)]

I don't completely understand why, but using Cedric's backport PPA in bug #873784 to get correct handling of the wtmp file also resolved the issue with the session selection for me. Worth a try for those who are affected by this bug.

[Christopher (christopher-redhat-bugs)]

This is a real pain in the neck. We use NIS for login, with quite a few user IDs below 1000. It would be a major impact to change all the uids, but it's possible (though a major PITA) to change to KDM on each install.

[Andrew (andrew-redhat-bugs)]

(In reply to comment #19)
> This is a real pain in the neck. We use NIS for login, with quite a few user
> IDs below 1000. It would be a major impact to change all the uids, but it's
> possible (though a major PITA) to change to KDM on each install.

I haven't noticed ~/.dmrc being used for any users, regardless of UID.

[Christopher (christopher-redhat-bugs)]

And /var/lib/AccountsService/users doesn't appear to be updated, either.

[Lisa Nelson (lisa50469)]

Still seeing this issue. Ubuntu 11.10 fully updated.
LDAP users login and it ignores desktop selection. Still doesn't work after logging out and back in. The users always get the Unity desktop. Hope this is fixed soon.

[Alex Bachmeier (cebalrai)]

I can confirm this bug for precise with nfs+ldap+kerberos.
The default session for users isn't saved in either lightdm or gdm, as both use accountsservice for session saving.

[Alex Bachmeier (cebalrai)]

Mounting the /var/lib/AccountsService directory through nfs from an external server might help get around this issue. I will see if this works.

[coli (sebastian-coli)]

Seems not to work. The problem also exists on NIS-environments.

[Fedora (fedora-redhat-bugs)]

This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Elliott (elliott-redhat-bugs)]

Although GDM now remembers a user's previous desktop manager in Fedora 16 and 17 it still does not recognize ~/.dmrc or any other config file in a user's home directory. This is a problem for distributed environments that use NFS shared home directories since a user has to select their desktop manager at each new machine. We have roughly 300 lab machines running Fedora and our users often complain that they accidentally forget to change their desktop manager at login, causing them to have to log in and out twice.

Maybe it is a feature request at this point but I kinda wish this bug would remain open on Fedora 17.

[Fedora (fedora-redhat-bugs)]

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

[Matthias (matthias-redhat-bugs)]

Lets close this. It is intentional that gdm is not touching the home directory.

[Ian (ian-redhat-bugs)]

What solution do you propose to cater for the NFS mounted home directory case?

[Andrew (andrew-redhat-bugs)]

(In reply to Matthias Clasen from comment #25)
> Lets close this. It is intentional that gdm is not touching the home
> directory.

Even if gdm doesn't touch the home directory, it would be a start to at least read from it.

(In reply to Ian Donaldson from comment #26)
> What solution do you propose to cater for the NFS mounted home directory
> case?

Indeed. There doesn't seem to be any proposed solution. But what can you expect to work when you use GNOME? :(

[Christopher (christopher-redhat-bugs)]

(In reply to Matthias Clasen from comment #25)
> Lets close this. It is intentional that gdm is not touching the home
> directory.

I believe the only possible answer to this is:

What.
The.
Fuck.
Are.
You.
Smoking?

You're deliberately ignoring what the user wants to do? I presume there is some rationale behind this other than "Hey, let's just make it a royal pain in the butt for people to use anything but GNOME! After all, that's worked so well for Microsoft!" but to be honest, whatever that reason might be, it's not exactly obvious to the casual observer.

[John (john-redhat-bugs)]

(In reply to Matthias Clasen from comment #25)
> Lets close this. It is intentional that gdm is not touching the home
> directory.

Dear Matthias,

I do not think that closing this bug is the proper way to handle it. I am not sure whether you are away of the original rationale behind the .dmrc file but there is a actually a very important one which is for the user being able to store the settings about the default session and language in a networked environment.

Many users, especially paying RedHat customers, are using gdm in a networked environment with homes shared over NFS and people not having a dedicated desktop computer. This means, they need a machine-independent way to store these settings, storing them in a /var subdirectory is completely useless in this setup.

If you decide to completely ignore this very important use case, it's your decision. However, since many users need gdm to work in that way, I am predicting more shifts away from GNOME or gdm in the future or one of RedHat's strategic customers writing a complaint (just look at GNOME bug #637095 plus the asssociated RH bugs #561904 and #902448) in the future so that you *have* to reopen and fix the bug. Remember, this is a feature enterprise customers need and use and by removing it, you are deliberately making their lifes harder.

Remember, it were actually actions like these from your side which made people fork GNOME and come up with alternatives like MATE.

Please consider reopening this bug, it's a mandatory feature in networked environments!

Adrian

[Elliott (elliott-redhat-bugs)]

I agree that this bug should not be closed. NFS mounted home directories are very common and, as it stands, users in such environments that choose not to use GNOME have to specify this every time they log in to a different machine.

This is the case for Fedora as well as RedHat environments. For example, I work in a university setting that uses Fedora extensively. Having NFS mounted home directories is ideal. This way a student can log in to any lab machine and work on their homework or research. People find it extremely bothersome to have to select their session at every login, imagine the cumulative time wasted clicking that menu.

Why would GDM deliberately avoid reading a user's preferences from their home directory? That makes no sense. After all, it is a user setting. There should be some mechanism for a user to select their default session.

[Matthias (matthias-redhat-bugs)]

You don't have to specify your default session every time you log in. gdm saves it outside the users home directory (in /var/lib/AccountsService/users/). At the worst, you have to choose a session the very first time you log in on a different machine.

[Ian (ian-redhat-bugs)]

And if you have a room with 100 machines in it and you sit at a different
desk nearly every day?

[John (john-redhat-bugs)]

(In reply to Matthias Clasen from comment #31)
> At the worst, you have to choose a session
> the very first time you log in on a different machine.

Well, we have around 50 machines in the students' computer pool at our physics department which means in the worst case students will have manually restore their choice 50 times. There are even more machines in larger departments at this university, so this number can be even higher.

Don't you agree that this is quite annoying, especially when the original design of the display manager perfectly solved this by storing this information in the user's home directory?

It's a user-specific setting, what exactly is the reasoning to store it outside the home directory in a local path?

Adrian

[Matthias (matthias-redhat-bugs)]

> It's a user-specific setting, what exactly is the reasoning to store it
> outside the home directory in a local path?

The reason is that the setting is needed outside the session, when it can't be guaranteed that the home directory exists (eg automount). Your password is user-specific too, and isn't stored in your home directory for more or less the same reason.

[Rex (rex-redhat-bugs)]

I'm sure accountsservice (or possibly sssd if it replaces it someday as threatened in http://www.freedesktop.org/wiki/Software/AccountsService/ ) could be taught to learn about network homes or network-wide settings.

Arguing for such in fedora's downstream bugzilla, however, is likely not a good way to facilitate making that happen.

[John (john-redhat-bugs)]

(In reply to Matthias Clasen from comment #34)
> The reason is that the setting is needed outside the session, when it can't
> be guaranteed that the home directory exists (eg automount). Your password
> is user-specific too, and isn't stored in your home directory for more or
> less the same reason.

Well, for one thing, if your home directory is on an automount it will be automatically mounted once the file is accessed, be it through systemd or autofs. It has been worked in the past without any problems, so I don't see why it should be a problem now.

As for the password, yes, it is not stored in your home directory. However, the password isn't stored locally either. It is retrieved and verified through NIS or similar services and therefore globally available and modifiable independent of the machine you are using. Your example actually is rather backing up my point than yours.

I'd be fine with dropping the .dmrc mechanism if there was an alternative mechanism to retrieve the sesssion information globally over the network, but there isn't which is really unfortunate.

Just imagine, if someone, for whatever reason decides to change their default session another time (I tend to be switching desktops/window maangers in the past quite often). They will have to go through this process over and over again.

Adrian

[John (john-redhat-bugs)]

(In reply to Rex Dieter from comment #35)
> I'm sure accountsservice (or possibly sssd if it replaces it someday as
> threatened in http://www.freedesktop.org/wiki/Software/AccountsService/ )
> could be taught to learn about network homes or network-wide settings.

Yes, we were actually proposing that during lunch today. However, the mechanism isn't there yet, so it isn't a good thing to remove the .dmrc mechanism first.

I honestly expect a complaint from a paying RHEL customer in the future like it happened with the gvfsd issue. The problem was absolutely analogous, GNOME developers not taking special precautions for networked environments which are the dominant form deployed by enterprise customers.

The University of Oslo is deploying RHEL 5.x and 6.x on a huge amount of desktop machines. I do not think that it will take very long until someone there sends in a complaint to RedHat.

Adrian

[Elliott (elliott-redhat-bugs)]

> At the worst, you have to choose a session
> the very first time you log in on a different machine.

We have 300 Fedora machines in our department and they all get re-imaged every 6-months for the next release of Fedora. So, a user could potentially have to select their session 600 times per year :) Besides, they can't be expected to recall which machines they have logged in to. For all practical purposes they have to do it every time.

>Arguing for such in fedora's downstream bugzilla, however, is likely not a good >way to facilitate making that happen.

There doesn't appear to be an AccountsService mailing list but perhaps it would be better to file a bug report upstream?

Between this and the fact that the "user list" feature cannot be disabled, GDM is basically unusable in distributed environments. I suppose we should all just accept this and start using a different session manager or else start contributing to GDM upstream.

[Elliott (elliott-redhat-bugs)]

>The reason is that the setting is needed outside the session, when it can't
>be guaranteed that the home directory exists (eg automount). Your password is
>user-specific too, and isn't stored in your home directory for more or less the >same reason.

I'm not buying this. If a user's home directory doesn't exist then I don't think they'll care about their default/previous session. If you are referring to automounted home directories then they should get mounted as soon as the file is queried, otherwise they are not going to be able to log in anyway.

[John (john-redhat-bugs)]

(In reply to Elliott Forney from comment #38)
> Between this and the fact that the "user list" feature cannot be disabled,
> GDM is basically unusable in distributed environments. I suppose we should
> all just accept this and start using a different session manager or else
> start contributing to GDM upstream.

Unfortunately, this functionality has only a half-baked implementation in lightdm, it restores only parts of the session information from .dmrc:

> https://bugs.launchpad.net/lightdm/+bug/1069494
> https://bugs.launchpad.net/lightdm/+bug/1068853
> https://bugs.launchpad.net/lightdm/+bug/1019314

So, until all of these bugs are fixed, lightdm isn't a viable alternative either. What we did was actually using a fork of gdm 2.20 and deployed it on our Debian Wheezy machines which uses gdm3 by default. This way, we also get the themes functionality back and the display manager works as expected.

Adrian

[Adam (adam-redhat-bugs)]

What is the next thing to gnome is going to "solve"?

[John (john-redhat-bugs)]

Just a short heads-up on this. Apparently, a paying RedHat customer also made a complaint regarding this issue and Ray Strode actually implemented a workaround for RHEL6 [1].

I am expecting another paying RHEL7 customer to file another bug against gdm3 in the not so distant future meaning that the GNOME developers will actually have to fix the issue for good.

I am pretty confident for this to happen as it did previously with a serious gvfs issue that was constantly hammering NFS servers. GNOME developers ignored the issue for several months or even years, then a paying "strategic" customer filed a complaint which got the whole thing escalated and the bug was fixed within two weeks.

It's a bit of a pity that GNOME developers apparently often need directions from the management to not ignore important user requests.

Adrian

> [1] https://bugzilla.redhat.com/show_bug.cgi?id=795920

[Derek (derek-redhat-bugs)]

Our current work around is to use the command:

gdbus call --system --dest org.freedesktop.Accounts --object-path /org/freedesktop/Accounts/User"$(id -u)" --method org.freedesktop.Accounts.User.SetXSession "1-kde-plasma-standard"

Even though this isn't as clean as executing ~/.xsession (RHEL5) or reading ~/.dmrc (RHEL6) it does allow you some type of automation when selecting a different session value when logging in at a console.

[Ian (ian-redhat-bugs)]

And does that work for the user if they sit at a different machine (in a lab of 50) the next day?