Package: systemd
Version: 231-6
Severity: normal

Dear Maintainer,

I wanted to set resource limits from a systemd _user_ unit, with:

  LimitRTPRIO=96
  LimitMEMLOCK=infinity


Raising resource limits with ulimit(3) or setrlimit(2) is a privileged
operation, however users are normally allowed to set resource limits
within the boundaries set by hard limits in /etc/security/limits.conf.

Currently this practice does not work with systemd user units.

For example, I have these settings in limits.conf:
-----------------------------------------------------------------------
*   hard  rtprio     96
*   hard  memlock    unlimited
-----------------------------------------------------------------------


The output of running prlimit from a shell is as follows:
-----------------------------------------------------------------------
RESOURCE   DESCRIPTION                             SOFT      HARD UNITS
...
MEMLOCK    max locked-in-memory address space     65536 unlimited bytes
...
RTPRIO     max real-time priority                     0        96 
...
-----------------------------------------------------------------------


And users are able to change the soft limit with ulimit from the shell.

However "systemd --user" seems to ignore the hard limits, see the unit
below (copied to /usr/lib/systemd/user/prlimit_defaults.service):
-----------------------------------------------------------------------
[Unit]
Description=Test setting limits

[Service]
ExecStart=/usr/bin/prlimit
-----------------------------------------------------------------------


Starting the unit with "systemctl --user start prlimit_defaults.service"
results in this output:
-----------------------------------------------------------------------
Started Test setting limits.
RESOURCE   DESCRIPTION                             SOFT      HARD UNITS
...
MEMLOCK    max locked-in-memory address space     65536     65536 bytes
...
RTPRIO     max real-time priority                     0         0
...
-----------------------------------------------------------------------


The limits are ignored and of course raising them does not work either:
-----------------------------------------------------------------------
[Unit]
Description=Test setting limits

[Service]
ExecStart=/usr/bin/prlimit

# These work fine when running the unit as a system service,
# but they don't have effect when using "systemctl --user"
LimitRTPRIO=96
LimitMEMLOCK=infinity
-----------------------------------------------------------------------


After a precious suggestion by Mantas Mikul─Śnas (grawity in
#debian-systemd) I verified that this is happening because
/etc/pam.d/systemd-user does not load pam_limits.so.

The following change fixes the issue:
-----------------------------------------------------------------------
--- /etc/pam.d/systemd-user.orig        2016-09-17 17:40:19.787522246 +0200
+++ /etc/pam.d/systemd-user     2016-09-17 15:13:17.035405264 +0200
@@ -7,5 +7,6 @@
 session  required pam_selinux.so close
 session  required pam_selinux.so nottys open
 session  required pam_loginuid.so
+session  required pam_limits.so
 @include common-session-noninteractive
 session optional pam_systemd.so
-----------------------------------------------------------------------


After adding pam_limits and the settings in limits.conf, the units from
above have the expected behavior.

The mechanism explained in systemd-user.conf(5) to set default limits
for all user units also works now; before it didn't.

For instance these values in /etc/systemd/user.conf were completely
ignored without the changes from above:
-----------------------------------------------------------------------
DefaultLimitMEMLOCK=infinity
DefaultLimitRTPRIO=96
-----------------------------------------------------------------------


I guess that too was because user.conf limits are meant to be within
some system-wide limits (see the P.S. below).

I can send a patch for /etc/pam.d/systemd-user against the systemd
Debian package to address the issue, but I have a doubt: can this also
be considered a bug in the upstream src/login/systemd-user.m4?

If so I will send a standalone patch which applies _before_
debian/Adjust-systemd-user-pam-config-file-for-Debian.patch this way it
will be easier to have it merged upstream.

Thanks,
   Antonio


P.S.

After I wrote the report above I found out that another way to solve the
problem is to set system-wide limits in /etc/systemd/system.conf (or
/lib/systemd/system.conf.d/nn_SOMETHING.conf), e.g.:

  [Manager]
  DefaultLimitMEMLOCK=65536:infinity
  DefaultLimitRTPRIO=0:96

and these limits will also apply to "systemd --user" (and so
/etc/systemd/user.conf will work too within these limits); maybe this is
even the "official" systemd way to solve the problem, but it does not
give the ability to set per-user or per-group limits, so I still think
that the report above is valid.


-- Package-specific info:

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (500, 'unstable-debug')
Architecture: amd64 (x86_64)

Kernel: Linux 4.7.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser         3.115
ii  libacl1         2.2.52-3
ii  libapparmor1    2.10.95-4
ii  libaudit1       1:2.6.6-1
ii  libblkid1       2.28.2-1
ii  libc6           2.24-3
ii  libcap2         1:2.25-1
ii  libcap2-bin     1:2.25-1
ii  libcryptsetup4  2:1.7.0-2
ii  libgcrypt20     1.7.3-1
ii  libgpg-error0   1.24-1
ii  libidn11        1.33-1
ii  libip4tc0       1.6.0-3
ii  libkmod2        22-1.1
ii  liblzma5        5.1.1alpha+20120614-2.1
ii  libmount1       2.28.2-1
ii  libpam0g        1.1.8-3.3
ii  libseccomp2     2.3.1-2
ii  libselinux1     2.5-3
ii  libsystemd0     231-6
ii  mount           2.28.2-1
ii  util-linux      2.28.2-1

Versions of packages systemd recommends:
ii  dbus            1.10.10-1
ii  libpam-systemd  231-6

Versions of packages systemd suggests:
ii  policykit-1        0.105-16
ii  systemd-container  231-6
pn  systemd-ui         <none>

Versions of packages systemd is related to:
ii  udev  231-6

-- no debconf information
-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Reply via email to