sddm-conf overwrites /etc/sddm.conf with a complete config
background
I had previously discovered that if /etc/sddm.conf did not explicitly have the theme specified, when you ran the “SDDM Configuration” (sddm-conf) tool and used it to save the configuration, it would essentially remove the theme. So I added it to /etc/sddm.conf.d/lubuntu_settings.conf.
The reason why: sddm-conf creates a whole complete configuration. And you give it permission to completely overwrite the existing configuration with it:
minimal steps to reproduce
I found this to be true even if no actual changes were made to the configuration. You can test this by doing the following:
If you’ve already used sddm-conf, copy /etc/sddm.conf to somewhere safe and create a new /etc/sddm.conf with only the following content:
Check the “autologin” box (changing state from default)
Uncheck the “autologin” box (thereby returning the state to default)
Click “Save”
Inspect /etc/sddm.conf and note that includes every single possible option rather than the 3 shown in the original
help needed
So here’s what needs to happen now:
We need to go through and decide on every single possible option most options and ship a Lubuntu sddm.conf. You can ignore the following:
Wayland section
Any of the following, at least assuming they have specified values:
Files
Directories
Commands
We need to make sure (I don’t even know, honestly) if sddm-conf respects other possible locations for configurations¹
Whatever change we make, we need to copy into the live environment and make sure it works correctly there, too (even though we don’t expect people to see/use SDDM there, it is being used)
We’ll need to add whatever change in Plucky to other supported releases.
I would really appreciate it if anyone can help out with #1.
upstream changes
In an ideal world, I would also like to see the following changes which will require new upstream code:
sddm-conf saves to /etc/sddm.conf.d¹.
sddm-conf creates a backup file with an easy option to switch back.
Ensure sddm-conf’s hardcoded default settings don’t conflict with those of SDDM (sddm --example-config). Might be good to check that against the defaults in sddm-conf. Seems strange that they’d be different.
sddm-conf should be making the most minimal changes, i.e. adding, deleting and/or modifying only those configuration options that have been selected to be changed.
In any case, issues should be opened upstream for these various concerns.
¹ From man sddm.conf:
Configuration loads all files in the configuration directories followed by the configuration file in the order listed below with the latter having highest prece‐
dence. Changes should be made to local configurations.
/usr/lib/sddm/sddm.conf.d
System configuration directory
/etc/sddm.conf.d
Local configuration directory
/etc/sddm.conf
Local configuration file for compatibility
It’s interesting that /etc/sddm.conf takes precedence, but “for compatibility,” as if that’s not the place the SDDM developers intend for the configuration to happen. That makes me think this should not be what sddm-conf is modifying.
This is a good question. Ultimately focus tends to be on Plucky, but we’ll need to see if the same problems exist in other supported release versions. That will need to come later. The first step to get it in stable versions will be to fix it in the development one.
Edited above to be more clear, but in general: VMs work for almost everything.
I am shocked we have not run into issues with this before, to be honest. Maybe no one uses it (I don’t)!
I followed your steps to reproduce the issue, using Lubuntu 24.04.
Three options did change to six in /etc/sddm.conf
General
Autologin
Theme
Users
Wayland
X11
yes, it would be good if either the immutable/disabled options weren’t there or at least commented as being immutable/disabled.
Why is SDDM Configuration in “Accessories” btw? Shouldn’t it be in Preferences? I think it was in preferences at one point; perhaps this is an upstream thing.
I followed your recipe and this is what I got on Oracular (looks like everything is filled out - note that the distribution had only the Session type defined i.e. 2 lines):
Also, seems clear that these defaults are hardwired somewhere else as I have changed things in the directories and they took effect. I think this is decent behavior as long as when the values are changed they are recognized.
It was in the Freedesktop main category “Utility” up to and including Plucky. I changed it to “Settings” but that change exists upstream.
To be clear, that corresponds with “Accessories” and “Preferences,” respectively. The lxqt-menu-data package provides /etc/xdg/menus/lxqt-applications.menu which is what sets what is displayed regardless of what is actually set.
Looks like we have a new version of sddm-conf with my change. I’ll probably pull that into Plucky before moving forward. Actually, I might not. I don’t necessarily want to bother with a Feature Freeze Exception when this is ultimately the only change besides translations.
Right, specifying InputMethod and Theme are changes new to Plucky.
Looks like we’ll need to do a Stable Release Update (SRU) after we fix this in Plucky. Revised the original post to reflect this. Thanks to you both for testing.
Like I said above, SDDM itself has its own defaults. In behavior typical of every other application I’ve come across, in the absence of an explicit configuration, SDDM just relies on those defaults. This is why we only had a two line config file. The defaults were fine, or at least not problematic.
The problem here is that I can’t even guarantee that the defaults that sddm-conf has (which are indeed hardcoded into it) match those that SDDM has.
I just compared what’s hardcoded in sddm-conf (to be clear, I’m not using the config file it spit out, but actually looking at the code itself) with SDDM’s defaults and it seems that the following are not specified by sddm-conf:
I think this is why it appears that some settings don’t seem to be affected, but others, like the theme, do. If we don’t explicitly specify them, we’re going to run into trouble with those items in particular.
That said, I think if we can indeed verify that sddm-conf respects values that already exist outside of the list above, then we can probably just focus our attention on those items.
Ough… things get complicated quickly, after the original design philosophy of SDDM got lost somewhere in history. Btw. the “S” in SDDM stood for “simple”. And that is what is should be. Just a front page to log in a desktop (of choice). No bells and whistles.
But, a nice effort to get it back on the rails again in Lubuntu, and perhaps upstream.
What a really neat feature of SDDM is, is the auto login facility. A presumably safe way of starting a desktop in Kiosk-mode unattendedly. I use that for streaming Spotify (also automatically started as a service) from a mini-PC with USB-dac (but no screen or keyboard - phones connect to the mini-PC and act as remote control). I have not figured out how to achieve this without SDDM - without explicitly logging in. Spotify needs the graphical target.
Remains a bit tricky though, because SDDM will somehow allow automatic login for a non-root user, even if that user has sudo rights. Perhaps someone can explain why that is safe. I have doubts, but benefit from it
What are the risks if someone connects a screen and keyboard/mouse to my unattended “kiosk”? The assigned autologin user is logged in, the desktop is running. Shutdown and reboot are certainly possible, local network access and maybe a lot more.
