Bug#827240: systemd: Difficulties configuring permissions of on-demand load device nodes

Pizzocel pizzican at pizzocel.canis.uberspace.de
Tue Jun 14 01:24:32 BST 2016


Package: systemd
Version: 230-2
Severity: normal

Dear Maintainer,

The behaviour of debian is currently quite confusing, if you want do set
the permission of a device node, for which on-demand loading is in
effect. Let's take uinput as an example.  Assume you want it to be
accessible by the input group. So you could add the following udev rule:

 KERNEL=="uinput", GROUP="input"

But after booting you might get this:

 > ls -l /dev/uinput crw------- 1 root root 10, 223 Jun 13 10:49 /dev/uinput

The udev rule has not been applied yet, as the uinput module is not
loaded.  Instead the creation of this node has been take care of by
kmod-static-nodes.service and systemd-tmpfiles-setup-dev.service. These
services cause the permissions to be set as above.

So you can only access uinput as root. But if you do, this is what happens:

 > touch /dev/uinput
 > ls -l /dev/uinput
 crw-rw---- 1 root input 10, 223 Jun 13 11:04 /dev/uinput

The access to /dev/uinput has triggered the on-demand load of the uinput
module and therby the udev rule was applied resulting in the new node
permission you can see above.


The situation is not satisfactory either, if you didn't want to use an
udev rule and just set the permissions temporarily by calling chgrp and
chmod, while the module uinput has not been loaded yet.  The directly
after the first access to uinput the permissions are reverted back, as
for example here:

 > touch /dev/uinput
 > ls -l /dev/uinput
 crw-rw---- 1 root input 10, 223 Jun 13 11:04 /dev/uinput

One work around is to not make use of on-deman loading and load the
uinput module at boot time or explicitely before first use.  Another
work around would be to copy /run/tmpfiles.d/kmod.conf (which was
created by kmod-static-nodes.service) to /etc/tmpfiles.d/kmod.conf and
edit the permissions to one's need.  The configuration in /etc/... then
overrides the one in /run/...  Thus, the device node would have the
desired permissions immediately after booting. But if the permissions
should not be changed, when on-demand loading occurs, the permissions
must also be set in the corresponding udev rule.  So we have to set the
same permissions in two different places.

I think there should be one place, where the permissions of device node
can be configures and which will be respected both by the creation of
the nodes at boot time and later when loading the module.

-- Package-specific info:

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (1001, 'testing'), (500, 'testing-updates'), (500,
'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.5.0-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser         3.114
ii  libacl1         2.2.52-3
ii  libapparmor1    2.10-4
ii  libaudit1       1:2.4.5-1+b1
ii  libblkid1       2.27.1-6
ii  libc6           2.21-9
ii  libcap2         1:2.24-12
ii  libcap2-bin     1:2.24-12
ii  libcryptsetup4  2:1.7.0-2
ii  libgcrypt20     1.7.0-2
ii  libgpg-error0   1.21-2
ii  libkmod2        21-1
ii  liblzma5        5.1.1alpha+20120614-2.1
ii  libmount1       2.27.1-6
ii  libpam0g        1.1.8-3.2
ii  libseccomp2     2.3.0-1
ii  libselinux1     2.4-3+b1
ii  libsystemd0     230-2
ii  mount           2.27.1-6
ii  util-linux      2.27.1-6

Versions of packages systemd recommends:
ii  dbus            1.10.8-1
ii  libpam-systemd  230-2

Versions of packages systemd suggests:
pn  systemd-container  <none>
pn  systemd-ui         <none>

Versions of packages systemd is related to:
ii  udev  229-3

-- Configuration Files:
/etc/systemd/timesyncd.conf changed [not included]

-- no debconf information



More information about the Pkg-systemd-maintainers mailing list