Bug 617465 - GDM ignores user's default session in ~/.dmrc
GDM ignores user's default session in ~/.dmrc
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gdm (Show other bugs)
19
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
: Reopened, Triaged
Depends On:
Blocks: 988732
  Show dependency treegraph
 
Reported: 2010-07-23 03:04 EDT by Karel Piwko
Modified: 2016-10-21 19:31 EDT (History)
24 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 988732 (view as bug list)
Environment:
Last Closed: 2013-05-30 22:32:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Karel Piwko 2010-07-23 03:04:08 EDT
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.
Comment 1 Tajidin Abdullah 2010-08-02 06:00:17 EDT
This bug has been triaged



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 2 Andrew McNabb 2010-11-04 15:23:18 EDT
I have run across this problem, too, on Fedora 14.
Comment 3 Andrew McNabb 2011-05-02 17:37:47 EDT
I have confirmed that this is still a problem in Fedora 15.
Comment 4 Ray Strode [halfline] 2011-05-02 17:46:44 EDT
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?
Comment 5 Andrew McNabb 2011-05-02 18:02:34 EDT
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.
Comment 6 Fedora Admin XMLRPC Client 2011-06-21 11:31:44 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 7 Fedora Admin XMLRPC Client 2011-06-21 11:33:46 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 8 Fedora Admin XMLRPC Client 2011-06-21 11:36:33 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 9 Fedora Admin XMLRPC Client 2011-06-21 11:39:47 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 10 Fedora Admin XMLRPC Client 2011-06-21 11:49:13 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 11 Fedora Admin XMLRPC Client 2011-06-21 11:51:45 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 12 Fedora Admin XMLRPC Client 2011-06-21 11:54:16 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 13 Fedora Admin XMLRPC Client 2011-06-21 11:55:24 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 14 Elliott Forney 2011-08-29 22:10:36 EDT
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.
Comment 15 Ian Donaldson 2011-09-11 05:47:33 EDT
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.
Comment 16 Ian Collier 2011-09-21 08:01:08 EDT
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
Comment 17 Konstantin Svist 2011-11-25 16:42:28 EST
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
Comment 18 Konstantin Svist 2011-11-30 14:11:56 EST
Actually, nevermind. I'll just use LXDM from now on
Comment 19 Christopher Heiny 2012-01-19 11:22:54 EST
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.
Comment 20 Andrew McNabb 2012-01-19 11:45:01 EST
(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.
Comment 21 Christopher Heiny 2012-01-19 12:14:18 EST
And /var/lib/AccountsService/users doesn't appear to be updated, either.
Comment 22 Fedora End Of Life 2012-08-07 15:40:41 EDT
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
Comment 23 Elliott Forney 2012-08-07 23:37:18 EDT
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.
Comment 24 Fedora End Of Life 2013-04-03 16:15:28 EDT
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
Comment 25 Matthias Clasen 2013-05-30 22:32:33 EDT
Lets close this. It is intentional that gdm is not touching the home directory.
Comment 26 Ian Donaldson 2013-05-30 22:44:53 EDT
What solution do you propose to cater for the NFS mounted home directory case?
Comment 27 Andrew McNabb 2013-05-30 23:17:36 EDT
(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? :(
Comment 28 Christopher Heiny 2013-05-31 01:31:31 EDT
(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.
Comment 29 John Paul Adrian Glaubitz 2013-05-31 01:59:18 EDT
(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
Comment 30 Elliott Forney 2013-05-31 04:58:07 EDT
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.
Comment 31 Matthias Clasen 2013-05-31 09:09:58 EDT
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.
Comment 32 Ian Donaldson 2013-05-31 09:12:34 EDT
And if you have a room with 100 machines in it and you sit at a different
desk nearly every day?
Comment 33 John Paul Adrian Glaubitz 2013-05-31 09:22:19 EDT
(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
Comment 34 Matthias Clasen 2013-05-31 09:25:35 EDT
> 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.
Comment 35 Rex Dieter 2013-05-31 09:28:26 EDT
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.
Comment 36 John Paul Adrian Glaubitz 2013-05-31 09:36:22 EDT
(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
Comment 37 John Paul Adrian Glaubitz 2013-05-31 09:42:54 EDT
(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
Comment 38 Elliott Forney 2013-05-31 09:50:37 EDT
> 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.
Comment 39 Elliott Forney 2013-05-31 09:54:19 EDT
>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.
Comment 40 John Paul Adrian Glaubitz 2013-05-31 10:02:09 EDT
(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
Comment 41 Adam Pribyl 2013-10-21 16:59:12 EDT
What is the next thing to gnome is going to "solve"?
Comment 42 John Paul Adrian Glaubitz 2015-03-31 16:11:00 EDT
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
Comment 43 Derek Schrock 2016-10-21 18:15:17 EDT
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.
Comment 44 Ian Collier 2016-10-21 19:31:30 EDT
And does that work for the user if they sit at a different machine (in a lab of 50) the next day?

Note You need to log in before you can comment on or make changes to this bug.