On Sun, Jul 26, 2026 at 1:39 AM Russell Coker <[email protected]> wrote: > > Currently we have the X login programs (sddm, gdm3, and probably others) using > systemd to create a session via /etc/pam.d/common-session which if there is a > typical desktop environment installed includes pipewire and on a laptop it > will include Bluetooth. While it is easy to imagine some uncommon situations > where those things could be useful for X login (bluetooth keyboard? audio > screen reader?) in most cases it won't be needed. > > Should we make it a standard practice to have configuration options for this > to allow the sysadmin to easily choose whether sddm/gdm3/whatever starts such > things? It shouldn't be THAT difficult for a sysadmin to put in symlinks in > the account configuration for sddm to make it not start such things, but it's > also not particularly easy.
What do you propose these configuration options look like, and where will they be stored? (Ideally there should be a mechanism for Debian to ship one set of configs, derivatives to override those, and administrators to in turn override those.) > For ssh on a system where you have a desktop environment installed all the > desktop programs that are started by systemd-user are run on a ssh login by > default. For a single user system this works well. For a system that many > developers ssh to but which has an X login at the console either for people to > control it via GUI tools or because it's the default and no-one uninstalled > those things you end up with every developer having a bunch of programs that > they never use running all the time. > > For ssh it would be good to have options to easily disable user units at a > default level (maybe in /etc/skel) and also have a good way of disabling > systemd in pam for a single daemon. Sure you could edit /etc/pam.d/sshd to > not include common-auth and then paste in the bits of common-auth you actually > want but that's ugly and will risk errors on upgrades. I'm not sure what "disabling systemd in pam" means? If you mean that an SSH login session won't be a "real" login session, that seems like a distinctly bad idea because it will mess with Polkit's idea of how the user is logged into the system (which will in turn affect what Polkit will and won't allow the user to do). > What do you think? As long as "everything" is started by default and one has to blacklist what they don't want, I don't see a problem with that. If whitelisting is desirable for some users, a "whitelist" mode that has to be explicitly turned on might also be useful. -- Aaron > -- > My Main Blog http://etbe.coker.com.au/ > My Documents Blog http://doc.coker.com.au/ > > >
