[systemd-devel] start user-service only with UID greater than 1000

[Jakob Schürz]

Hi There!

I have two services running in systemd --user, which should only be
startet for login-users.
If i put the service-file by a deb-package in /usr/lib/systemd/user, the
service will also be started for Debian-exim, Debian-gdm and other users
with a UID below 1000. And this is not "good"...

Is there a mechanism in systemd --user to start services only for UIDs >
1000 (on Debian... other Distros may have the first login-user with
UID=500... how can i catch this?)
Or is it possible, to start Units only, if the user is in a special
unix-group? For example a group called "cups-fuse" or "backup", then the
service is startet in the users systemd only, if the user is in this group.

For now i have a

[Service]
ExecStartPre=/bin/sh -c '/usr/bin/test %U -ge 1000'

This produces a failed unit... That is not "beautiful" and leads to
wrong thoughts, watching the journal.

I need this services really only for logged in real users. Not
Debian-gdm or Debian-exim. And i need a solution, to activate it per
package-installation automatically for all the users who should be able
to login...

Maybe a Condition for a set usershell or another item, which identifies
a user as a login-user...

Any ideas or suggestions?

regards

jakob

[Mantas Mikulėnas]

That might be nice... but, how come your services register a logind session
in the first place? That doesn't happen unless something deliberately calls
pam_systemd – and the service startup process generally doesn't involve
calling PAM in the first place. So something doesn't add up. (Are you using
su?)

(GDM is an exception – the service is not in a logind session, but the
login screen (greeter) *is*, and it might rely on user@ being available
just like a regular GNOME session.)

Post by Jakob Schürz
Hi There!
I have two services running in systemd --user, which should only be
startet for login-users.
If i put the service-file by a deb-package in /usr/lib/systemd/user, the
service will also be started for Debian-exim, Debian-gdm and other users
with a UID below 1000. And this is not "good"...
Is there a mechanism in systemd --user to start services only for UIDs >
1000 (on Debian... other Distros may have the first login-user with
UID=500... how can i catch this?)
Or is it possible, to start Units only, if the user is in a special
unix-group? For example a group called "cups-fuse" or "backup", then the
service is startet in the users systemd only, if the user is in this group.
For now i have a
[Service]
ExecStartPre=/bin/sh -c '/usr/bin/test %U -ge 1000'
This produces a failed unit... That is not "beautiful" and leads to
wrong thoughts, watching the journal.
I need this services really only for logged in real users. Not
Debian-gdm or Debian-exim. And i need a solution, to activate it per
package-installation automatically for all the users who should be able
to login...
Maybe a Condition for a set usershell or another item, which identifies
a user as a login-user...
Any ideas or suggestions?
regards
jakob
_______________________________________________
systemd-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[Jakob Schürz]

Post by Mantas Mikulėnas
That might be nice... but, how come your services register a logind
session in the first place? That doesn't happen unless something
deliberately calls pam_systemd – and the service startup process
generally doesn't involve calling PAM in the first place. So something
doesn't add up. (Are you using su?)

Good point!
The User-Session for Debian-exim maybe really come from a su in a
script... I rewrote this script, now the User-Session for Debian-gdm
seems not to be startet again.

But gdm... it starts this service, in case of starting a user-session
for systemd.
This seems to be another Problem, understanding the following answers
from the others in this thread...

Thanks for your suggestion.

Jakob

[Lennart Poettering]

Post by Jakob Schürz

Post by Mantas Mikulėnas
That might be nice... but, how come your services register a logind
session in the first place? That doesn't happen unless something
deliberately calls pam_systemd – and the service startup process
generally doesn't involve calling PAM in the first place. So something
doesn't add up. (Are you using su?)

Good point!
The User-Session for Debian-exim maybe really come from a su in a
script... I rewrote this script, now the User-Session for Debian-gdm
seems not to be startet again.

util-linux' "setpriv" is the correct to use for acquiring system user
privileges without setting up a full login session.

Post by Jakob Schürz
But gdm... it starts this service, in case of starting a user-session
for systemd.
This seems to be another Problem, understanding the following answers
from the others in this thread...

This is actually intended behaviour: gdm sessions are supposed to be
similar to normal sessions as possible.

BTW there's currently a PR being discussed that would permit you
to do per-user discrimination via a condition:

https://github.com/systemd/systemd/pull/5926

It's not merged yet though, and in its current version only permits
explicit user or group checks, not full ranges. (that said, extending
things like that definitely would make sense)

Lennart

[Lennart Poettering]

Post by Jakob Schürz
Hi There!
I have two services running in systemd --user, which should only be
startet for login-users.
If i put the service-file by a deb-package in /usr/lib/systemd/user, the
service will also be started for Debian-exim, Debian-gdm and other users
with a UID below 1000. And this is not "good"...

These users should not have a PAM session normally, and hence no
logind session either, and hence no systemd --user instance
either. There's something really strange if you actually do get PAM
sessions for these... Any idea why you get them?

Lennart

[Michael Biebl]

Afaics, the logind/PAM session for gdm/Debian-gdm is deliberate. gdm
spawns that via gdm-launch-environment, see
/etc/pam.d/gdm-launch-environment, which in turn includes
pam_systemd.so

Post by Lennart Poettering

Post by Jakob Schürz
Hi There!
I have two services running in systemd --user, which should only be
startet for login-users.
If i put the service-file by a deb-package in /usr/lib/systemd/user, the
service will also be started for Debian-exim, Debian-gdm and other users
with a UID below 1000. And this is not "good"...

These users should not have a PAM session normally, and hence no
logind session either, and hence no systemd --user instance
either. There's something really strange if you actually do get PAM
sessions for these... Any idea why you get them?
Lennart
--
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[Colin Guthrie]

Post by Michael Biebl

Post by Lennart Poettering

Post by Jakob Schürz
Hi There!
I have two services running in systemd --user, which should only be
startet for login-users.
If i put the service-file by a deb-package in /usr/lib/systemd/user, the
service will also be started for Debian-exim, Debian-gdm and other users
with a UID below 1000. And this is not "good"...

These users should not have a PAM session normally, and hence no
logind session either, and hence no systemd --user instance
either. There's something really strange if you actually do get PAM
sessions for these... Any idea why you get them?

Afaics, the logind/PAM session for gdm/Debian-gdm is deliberate. gdm
spawns that via gdm-launch-environment, see
/etc/pam.d/gdm-launch-environment, which in turn includes
pam_systemd.so

And I think this is needed and desirable for stuff like pulseaudio for
audio feedback for the login window etc. which would be launched via
socket activation from the systemd --user session ideally.

Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/

[Jakob Schürz]

Post by Lennart Poettering

Post by Jakob Schürz
Hi There!
I have two services running in systemd --user, which should only be
startet for login-users.
If i put the service-file by a deb-package in /usr/lib/systemd/user, the
service will also be started for Debian-exim, Debian-gdm and other users
with a UID below 1000. And this is not "good"...

These users should not have a PAM session normally, and hence no
logind session either, and hence no systemd --user instance
either. There's something really strange if you actually do get PAM
sessions for these... Any idea why you get them?

I have no idea, why this users get a PAM-Session.
Now i can see there is also a systemd --user process for
debian-security-support:


Jul 25 23:54:49 aldebaran systemd[1]: Starting User Manager for UID 137...
Jul 25 23:54:49 aldebaran systemd[6366]: pam_unix(systemd-user:session):
session opened for user debian-security-support by (uid=0)
Jul 25 23:54:49 aldebaran systemd[6366]: Listening on Sound System.
Jul 25 23:54:49 aldebaran systemd[6366]: Listening on GnuPG network
certificate management daemon.
Jul 25 23:54:49 aldebaran systemd[6366]: Started mkbackup-userdir.path.
Jul 25 23:54:49 aldebaran systemd[6366]: Listening on GnuPG
cryptographic agent (ssh-agent emulation).
Jul 25 23:54:49 aldebaran systemd[6366]: Listening on GnuPG
cryptographic agent and passphrase cache (restricted).
Jul 25 23:54:49 aldebaran systemd[6366]: Listening on GnuPG
cryptographic agent (access for web browsers).
[...]

I don't know, why this session ist startet for the user with UID 137

I get this session every time on "dpkg-reconfigure debian-security-support"

Jakob

[Simon McVittie]

Post by Jakob Schürz
I have no idea, why this users get a PAM-Session.
Now i can see there is also a systemd --user process for
Jul 25 23:54:49 aldebaran systemd[1]: Starting User Manager for UID 137...
session opened for user debian-security-support by (uid=0)

From https://sources.debian.net/src/debian-security-support/2017.06.02/debian/debian-security-support.postinst/
it looks as though that package is using su. It should probably be using

runuser -u "$USERNAME" /bin/bash -c "..."

instead, because whatever the question is, su is usually the wrong answer.

Presumably the other daemons you mentioned are also using su in a cron job
or maintainer script or something.

On my Debian system, /etc/pam.d/su pulls in /etc/pam.d/common-session,
which uses pam_systemd; but /etc/pam.d/runuser does not. So anything that
calls su will get a login session, with the side effect of a `systemd --user`,
but anything that calls runuser will not get a login session and a
`systemd --user`.

S