Your message dated Wed, 4 Sep 2019 20:49:53 +0200
with message-id <[email protected]>
and subject line Re: systemd: Difficulties configuring permissions of on-demand
load device nodes
has caused the Debian Bug report #827240,
regarding systemd: Difficulties configuring permissions of on-demand load
device nodes
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
827240: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827240
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
Version: 243~rc2-1
On Tue, 14 Jun 2016 02:24:32 +0200 Pizzocel
<[email protected]> wrote:
> 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.
https://github.com/systemd/systemd/issues/13350 seems related here.
This was fixed upstream by provided a static-nodes-permissions.conf
tmpfile. Unfortunately this means two places where to configure
permissions, but apparently there is no nicer way to do this.
Regards,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
--- End Message ---
_______________________________________________
Pkg-systemd-maintainers mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
