Re: systemd-user, daemons, and ssh sessions

On Sun, Jul 26, 2026 at 1:39=E2=80=AFAM 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 i=
t
> will include Bluetooth.  While it is easy to imagine some uncommon situat=
ions
> 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 t=
his
> 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 th=
e
> 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 ma=
ny
> developers ssh to but which has an X login at the console either for peop=
le to
> control it via GUI tools or because it's the default and no-one uninstall=
ed
> those things you end up with every developer having a bunch of programs t=
hat
> 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 act=
ually
> 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/
>
>
>