lsattr loading modules, changing permissions of device nodes

Marc Haber mh+pkg-systemd-maintainers at
Tue Mar 16 20:08:30 GMT 2021

Hi Michael,

thanks for the quick answer. I found out that I am actually subscribed
to pkg-systemd-maintainers.

On Tue, Mar 16, 2021 at 08:25:43PM +0100, Michael Biebl wrote:
> Am 16.03.21 um 19:50 schrieb Marc Haber:
> > * Why does, for example, the /dev/btrfs-control device node get created
> >    with one set of owner/mode and then gets converted to a different one
> >    when someone accesses it? btrfs-progs are not installed, btrfs is not
> >    in use.
> What you see are the default permissions of the devices. Once the device is
> marked as ready by the kernel and a uevent is emitted, udev will run its
> rules and apply the permissions. In this case
> # grep btrfs-control /lib/udev/rules.d/*
> /lib/udev/rules.d/50-udev-default.rules:KERNEL=="btrfs-control",
> GROUP="disk"

And what creates the device node with root:root 600, which I see before
the lsattr call?

> You can manually trigger a uevent by e.g.
> echo change > /sys/class/misc/btrfs-control/uevent

That file doesn't exist here:
|root at testsid85:~# ls -al /dev/btrfs-control
|crw------- 1 root root 10, 234 Mär 16 20:37 /dev/btrfs-control
|root at testsid85:~# echo change > /sys/class/misc/btrfs-control/uevent
|-bash: /sys/class/misc/btrfs-control/uevent: No such file or directory
|root at testsid85:~# ls -al /dev/btrfs-control
|crw------- 1 root root 10, 234 Mär 16 20:37 /dev/btrfs-control
|root at testsid85:~# lsattr /dev/btrfs-control
|lsattr: Operation not supported While reading flags on /dev/btrfs-control
|root at testsid85:~# ls -al /dev/btrfs-control
|crw-rw---- 1 root disk 10, 234 Mär 16 20:40 /dev/btrfs-control
|root at testsid85:~#

> Has systemd-udev-trigger.service been run successfully during boot?

Looks this way:
| [2/3938]mh at testsid85:~ $ sudo systemctl status systemd-udev-trigger
| ● systemd-udev-trigger.service - Coldplug All udev Devices
|      Loaded: loaded (/lib/systemd/system/systemd-udev-trigger.service; static)
|      Active: active (exited) since Tue 2021-03-16 20:37:11 CET; 1min 14s ago
|        Docs: man:udev(7)
|              man:systemd-udevd.service(8)
|     Process: 185 ExecStart=udevadm trigger --type=subsystems --action=add (code=exited, status=0/SUCCESS)
|     Process: 193 ExecStart=udevadm trigger --type=devices --action=add (code=exited, status=0/SUCCESS)
|    Main PID: 193 (code=exited, status=0/SUCCESS)
|         CPU: 45ms
| Mär 16 20:37:11 testsid85 systemd[1]: Finished Coldplug All udev Devices.
| Warning: journal has been rotated since unit was started, output may be incomplete.
| [3/3939]mh at testsid85:~ $

> I don't remember any udev related changes which could cause this.
> From which version to which version did you upgrade?

I have seen the really blatant behavior concerning the tty device nodes
first on March 13. The machine in question is my test environment for
unstable and is updated rather frequently. It got udev 247.3-2 on March
11 and 247.3-3 on March 12. Otoh, going back to udev 247.3-1 has the
same behavior.

straceing udev confirms that udev does something (such as creating
/dev/char/10:234 as symlink to /dev/btrfs-control) when I issue the
lsattr call, but I don't see any syscalls that might be changing the
group and the mode of the file. This is mysterious. What else might be
doing these changes?


Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

More information about the Pkg-systemd-maintainers mailing list