RUN{builtin}+="uaccess" won't work with eudev

[abucodonosor]

Hello,

while playing around with elogind and eudev we noticed the following error

RUN{builtin}: 'uaccess' unknown /lib/udev/rules.d/73-seat-late.rules:15

Regards

[Yamakuzure]

Interesting. The file hasn't changed for over 5 years, so I am wondering what that is.

I am using eudev on all my machines, too, and never have seen such an issue.

Please tell me:

• Which version of elogind are you using?
• Which version of eudev are you using?
• What is your "PID 1"?
• How can this (error?) message be reproduced?

[udeved]

This happens, if the udev directory isn't properly configured in make.

Works for me if

--with-rootlibdir=/usr/lib \
--with-udevrulesdir=/usr/lib/udev/rules.d \
--prefix=/usr \
--libdir=/usr/lib
--libexecdir=/usr/lib

If the linux distro uses /usr prefix, then this error points to misconfigured udev...

 RUN{builtin}: 'uaccess' unknown /lib/udev/rules.d/73-seat-late.rules:15

[abucodonosor]

@udeved This is not about the rules.d dir .. we use /lib/udev/ rules.d..

Also the error tells 'udev' has no such 'builtin'

Are you sure your initrd is systemd free ?

@Yamakuzure I play with 'finit' and the versions we use are the following
elogind 227.4
eudev 3.2.2
finit is 3.0rc2 ( however we work on getting stuff upstream )

I think a easy way to reproduce will be
get a minimal initramfs ( simple one with dracut and all systemd stuff disabled in it )
be sure you have that rule installed in initramfs and only eudev
boot with init=/bin/bash

The problem is the 'acl' option I guess see
systemd/systemd#4107

In the past for uaccess systemd got some systemd-uaccess helper
which got changed to udev builtin.. so when you use --enable-acl
in systemd 'the systemd udev version' builds the udev code and
builtin 'uaccess' is available.

So after all this seems to be an eudev feature .. or you revert back to helper app
of uaccess.

Regards

[abucodonosor]

https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin.c#L45

While no such code exists in eudev..

[udeved]

@abucodonosor

Yes, I am sure, I had this error once when elogind didn't have proper udev rules dir.

[abucodonosor]

@Yamakuzure

or even shorter test

udevadm test /dev/sda ( or whatever else , doesn't matter )

....
Reading rules file: /lib/udev/rules.d/70-touchpad.rules
Reading rules file: /lib/udev/rules.d/70-uaccess.rules
Reading rules file: /lib/udev/rules.d/71-seat.rules
Reading rules file: /lib/udev/rules.d/73-seat-late.rules
RUN{builtin}: 'uaccess' unknown /lib/udev/rules.d/73-seat-late.rules:15
Reading rules file: /lib/udev/rules.d/75-net-description.rules
...

or start udevd manually in a chroot

...

starting version 3.2.2
RUN{builtin}: 'uaccess' unknown /lib/udev/rules.d/73-seat-late.rules:15

...

also run

udevadm test-builtin on eudev and systemd-udevd ( compiled with ACL )

[abucodonosor]

@udeved

( off topic here )

not only the rules here have some problems ..

you may want to look lvm2 and mdadm udev rules..
they have ENV{SYSTEMD_WANTS}+="some.service" etc

this bug can be even reproduce with systemd-udevd like this

recompile systemd 'without' ACL , create some chroot , install this version there ,
and fire up udevadm test .. you have same error..

[udeved]

@abucodonosor

What distro are you using?
My lvm udev rules look fine, the lvm package is compiled without systemd.

However, @Yamakuzure , I can confirm the late seat error o one of my testing machines. apparently, no error on laptop, but error on the normal box.

May 8 08:00:55 manjaro kernel: udevd[596]: RUN{builtin}: 'uaccess' unknown /usr/lib/udev/rules.d/73-seat-late.rules:15

[abucodonosor]

@udeved

I use Frugalware Linux .. ( btw are you on irc somwhere on freenode ? )

Have a look at

69-dm-lvm-metad.rules and 63-md-raid-arrays.rules

[Yamakuzure]

@abucodonosor I can reproduce this with the short "udevadm test <foo>" example.
Interesting.

I'll see what I can get from these links. If UACCESS needs some systemd-only helper, then it is unneeded anyway.

From a first glance it seems, that you would not get this error with systemd-udev, but only with eudev, right? If this is the case, then it seems to me, that eudev needs an update.

[abucodonosor]

@Yamakuzure

You can reproduce the issue with systemd-udev too when you compile the whole thing with

--disable-acl .. which is the problem here.

upstream, they have some defines for acl/no-acl and based on that udevd gets 'builtin uaccess' or not.

https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin.c#L45

for eudev one would need to get the uaccess code in and then you need to add the --acl option
to eudev .. just not sure eudev upstream want this.

[Yamakuzure]

Hmm... I have just seen this:

https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-uaccess.c#L40

I I am not entirely wrong, it means, that UACCESS isn't needed for anything unless systemd runs the show.
So there are two fixes for the problem:

1. Right now ignore the error, it is harmless
2. I will, once my laptop is up and running again, delete the offending line from 73-seat-late.rules, until eudev gets an update implementing UACCESS.

[abucodonosor]

they check there for .. if (!logind_running()) .. well yes the comment tells systemd since they won't care
about any other forks of logind ..

since I didn't really looked what parts of logind && systemd elogind is really using I don't know you need
uaccess part or not..

however if not you may want remove all ACL code && rules since they do nothing then

[udeved]

Thought it would be good idea to open an issue on eudev, so this can be cooperatively tackled perhaps. :)

[Yamakuzure]

@udeved : If you hadn't done that, I would have. ;-)

The UACCESS line in the rules file should only be there if --enable-acl was set. Actually supporting it is the task of whoever sets up the device.

So an update to eudev would be nice.

[Yamakuzure]

Anthony (aka "blueness") eventually answered @ eudev-project/eudev#145 (comment) :

I've resisted putting acl's into eudev, but it looks like you guys need it. I'll play with it a bit and try to get something out in v3.3

yay!

[ghost]

same happens to me in Artix @udeved .
I get in dmesg:

[  145.550897] udevd[687]: RUN{builtin}: 'uaccess' unknown /usr/lib/udev/rules.d/73-seat-late.rules:15

and my 73-seat-late.rules is this:

$ cat /usr/lib/udev/rules.d/73-seat-late.rules 
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

ACTION=="remove", GOTO="seat_late_end"

ENV{ID_SEAT}=="", ENV{ID_AUTOSEAT}=="1", ENV{ID_FOR_SEAT}!="", ENV{ID_SEAT}="seat-$env{ID_FOR_SEAT}"
ENV{ID_SEAT}=="", IMPORT{parent}="ID_SEAT"

ENV{ID_SEAT}!="", TAG+="$env{ID_SEAT}"

TAG=="uaccess", ENV{MAJOR}!="", RUN{builtin}+="uaccess"

LABEL="seat_late_end"

My packages:

$ pacman -Qs systemd
local/elogind 234.4-3
    The systemd project's logind, extracted to a standalone package
local/lib32-systemd 233.75-2
    system and service manager (32-bit)
local/libsystemd-dummy 233-1
    systemd client libraries without udev; systemd compatibility package
local/opensysusers 0.3.1-1
    A standalone utility for handling systemd-style sysusers.d users and groups
local/opentmpfiles 0.1.3-5 (base)
    A standalone utility for handling systemd-style tmpfiles.d settings
local/polkit 0.113+29+g3272a98-10
    PolyciKit with elogind support for non-systemd systems
local/systemd-dummy 233-1
    systemd-sysuser and systemd-tmpfiles binary; systemd compatibility package

[ghost]

Strange if I have a root logged in ttyX, then I have no error!

[Yamakuzure]

That error should only be printed on boot, not on every user login.

[Yamakuzure]

In issue #43 the idea arose to let elogind catch device ADD events and then apply the users ACLs on it directly instead of waiting for [e]udev to do it initially. elogind already applies the users ACLs on all uaccess and activated devices on vt switches, so if catching device ADD events isn't too difficult to achieve, two issues can be handled with one update.

[Yamakuzure]

This issue might be fixed with pull request #47

[Yamakuzure]

Please check whether this is fixed with the Version 235.3 Release.

[yshui]

@Yamakuzure I can confirm it works for me.

[Yamakuzure]

Thank you very much, it works for me, too.