Who though user desktop-selection being stored per-machine was a good idea?

This has been around for a while, but is still a thorn in my side: Who though it was a good idea to no longer store a user’s desktop selection (kde, gnome, etc) w/in the user’s home directory and move it to per-machine storage beneath /var/lib/AccountsService?

I’ve got users who aren’t savvy about ‘desktops’. When their machine is upgraded or even simply replaced because of failed hardware, they say “It doesn’t look the same!” If I ask, “What desktop were you using?”, they have no idea what I am talking about. I certainly don’t know what desktop they were using. The best I can do is manually step them through the login process selecting each desktop in turn asking, “Is this what it looked like?”

Addendum 2023-09-23: Just to be clear here, the situation I’m dealing w/ here is where users have their own workstations sitting on their desk, but their home directories live on a central file-server, and password/login info comes from a central LDAP server.

Does this question’s reply explain it? Why does AccountsService keep locale configuration? And why in the path /var/lib/AccountsService/users/? - Desktop - GNOME Discourse

There are reasons why some user-specific metadata needs to be stored outside of the user’s home directory. E.g. the home directory may be encrypted and require the user’s password to mount. If you want to know the user’s locale so you can show them the password prompt translated into the right language, you cannot rely on the home directory being already mounted.

1 Like

That might make some small sense for locale info, but not, IMAO, for desktop choice. And even for locale info for trying to select the proper language for the password prompt, it won’t ever work for the username prompt, and if it’s the first time a user uses a machine, it won’t work for the password prompt either, so I fail to see any real usefulness of it.

You can use an extra LDAP attribute or local config to store the session name.
Then use a script to check the current session name and load the last used one if empty.

That would be a valid mechanism for obtaining that info. I agree. But it would have to be built into the session start-up code, as well as a mechanism for storing that info, and it currently isn’t; all that is there is just the existing–IMAO broken–behavior. At the current time, I’m not looking to rewrite an entire new replacement for gdm and the session startup code.

As is implied any information that will be needed before the home dir is mounted cannot be in the home dir.

I have not checked specifically for what you are concerned about if that is also the case, but its seem likely.

FYI AccountsService is also new to me and I have started to research it.

User desktop choice may need to be visible in cases where a particular desktop has an unpatched security issue or creates problems for a “mission-critical” application. In such cases, notifications can target to affected users and follow-up done without annoying all the users of unaffected desktops (and attempts to switch to the unwanted desktop can be detected).

Anything of that sort can easily be deferred until after the user’s home directory has been mounted and just before the desktop session is started.

While the user can explicitly state what desktop they want for the current login session during the login prompting, what they choose isn’t actually used until the session is initiated, and for that their home directory has to be already mounted, so it is completely reasonable to leave the determination of what desktop to use if the user hasn’t entered an explicit choice to that point in time.

Here are the functions to save/restore the session:

sudo tee /etc/profile.d/session-conf.sh << "EOI" > /dev/null
session_save() {
	if [ -z "${XDG_SESSION_DESKTOP}" ] \
	|| [ -z "${XDG_SESSION_TYPE}" ]
	then return 0
	mkdir -p "${XDG_SESSION_CONF%/*}"
	tee "${XDG_SESSION_CONF}" << EOF > /dev/null

session_restore() {
	local XDG_SESSION_DESKTOP="$(busctl -j \
		get-property org.freedesktop.Accounts \
		/org/freedesktop/Accounts/User"${USER_UID}" \
		org.freedesktop.Accounts.User Session \
		| jq -r .data)"
	local XDG_SESSION_TYPE="$(busctl -j \
		get-property org.freedesktop.Accounts \
		/org/freedesktop/Accounts/User"${USER_UID}" \
		org.freedesktop.Accounts.User SessionType \
		| jq -r .data)"
	if [ -n "${XDG_SESSION_DESKTOP}" ] \
	&& [ -n "${XDG_SESSION_TYPE}" ]
	then return 0
	elif [ ! -e "${XDG_SESSION_CONF}" ]
	then return 1
	busctl call org.freedesktop.Accounts \
		/org/freedesktop/Accounts/User"${USER_UID}" \
		org.freedesktop.Accounts.User \
		SetSession s "${XDG_SESSION_DESKTOP}"
	busctl call org.freedesktop.Accounts \
		/org/freedesktop/Accounts/User"${USER_UID}" \
		org.freedesktop.Accounts.User \
		SetSessionType s "${XDG_SESSION_TYPE}"

USER_UID="$(id -u "${USER_NAME}")"
USER_HOME="$(eval echo ~"${USER_NAME}")"

The problem is to trigger the restore function before the user logins.
In theory, you can call the restore function in a loop over the LDAP users at startup.

1 Like

No, I don’t think I’d want to run this restore over all 600+ users at system startup. Also, that would miss if they updated their desktop choice on some other system between the time the system was booted and the time they log in.

I may just try to hack /usr/bin/gnome-session (and any kde, or other equivalents) to divert to a different session depending on the content of ~/.dmrc.

And a quick side note: What is this odd tee file <<EOI >/dev/null construct you are using? Whey not just cat >file <<EOI? Is there some special behavior from using ‘tee’?

1 Like

I agree, this method doesn’t scale so well.

Yes, it would require to rewrite the AccountsService config without checking its contents.

tee is just a bit more flexible since cat is problematic to combine with sudo.

Like many decisions over configuration defaults, some use cases are adversely affected. The default needs to consider security, scaling, certifications (e.g., out of box energy efficiency), etc.
Waiting for user logins ties timing of notifications to logins.

Wait, you’re not talking about giving notices when they try to login, but sending them out (presumably by email) w/out them even attempting logins? In that case, I would think that having the data stored per-machine would be more complicated than having the data stored in home directories. W/ home directory data, you would only have to scan user home directories on the central file-server, while w/ per-machine data, you would have to probe every workstation to see who might have a troublesome configuration. That can be especially difficult if some of the workstations get turned off. You might have a few file-servers, but you might have hundreds of workstations.

Apparently there were plans to provide the org.freedesktop.Accounts D-Bus API by SSSD, but I’m not sure how much of that is currently implemented.

Yeah, I saw that. It didn’t look like that went anywhere. It doesn’t appear to be active to my eye. Especially since the latest version they mention on that page is 2.0 and the current sssd is 2.8

The folks on the GNOME forum suggest to store the AccountsService data directory on the server along with the home directory, this sounds promising as it scales well and should solve the core problem.

I expect what is needed is to explain the reasoning behind moving to the “AccountsService” setup in the first place. That’s not meant as a hostile question, rather to see what issues were being addressed in the first place. Then if the design/implementation needs to be tweaked we could see what use-cases were missed.