Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

open_by_handle_at: Too many levels of symbolic links #2

Closed
xse opened this issue Feb 9, 2021 · 4 comments
Closed

open_by_handle_at: Too many levels of symbolic links #2

xse opened this issue Feb 9, 2021 · 4 comments

Comments

@xse
Copy link

xse commented Feb 9, 2021

Hi, i can reliably trigger this error just by launching systemctl list-unit-files on the following system:

model name      : ARMv6-compatible processor rev 7 (v6l)
Hardware        : BCM2835
Model           : Raspberry Pi Model B Plus Rev 1.2
xse@buttplug ~ % uname -a
Linux buttplug 5.10.14-1-ARCH #1 SMP Mon Feb 8 16:05:41 UTC 2021 armv6l GNU/Linux

I don't really know how to figure out what's going on.
Here is an example error output:

systemd(1): O /
systemd(1): O /etc
systemd(1): CO /
systemd(1): CO /etc/systemd
systemd(1): CO /etc
systemd(1): CO /etc/systemd/system
systemd(1): CO /usr
systemd(1): CO /usr/local
systemd(1): CO /usr/local/lib
systemd(1): CO /usr/lib
systemd(1): CO /usr/lib/systemd
systemd(1): CO /usr/lib/systemd/system
systemd(1): CO /
systemd(1): O /etc/systemd/system
systemd(1): RCO /etc/systemd/system
systemd(1): CO /
systemd(1): CO /etc
systemd(1): CO /etc/systemd
fatrace: open_by_handle_at: Too many levels of symbolic links

What seem to happens is that systemd opens random files with openat and get the ELOOP
from strace -e openat -f -p 1 -o openat.log:

root@buttplug ~ # cat openat.log | grep ELOOP
1     openat(AT_FDCWD, "/etc/systemd/system/dbus-org.freedesktop.network1.service", O_RDONLY|O_NOCTTY|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC) = -1 ELOOP (Too many levels of symbolic links)
1     openat(AT_FDCWD, "/etc/systemd/system/dbus-org.freedesktop.timesync1.service", O_RDONLY|O_NOCTTY|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC) = -1 ELOOP (Too many levels of symbolic links)
1     openat(AT_FDCWD, "/etc/systemd/system/dbus-org.freedesktop.resolve1.service", O_RDONLY|O_NOCTTY|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC) = -1 ELOOP (Too many levels of symbolic links)
1     openat(AT_FDCWD, "/usr/lib/systemd/system/autovt@.service", O_RDONLY|O_NOCTTY|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC) = -1 ELOOP (Too many levels of symbolic links)

Fanotify then gives those file handles to fatrace that tries to open em with open_by_handle_at and can't do so.
I assume that's what happens tbh i don't know how to link the handles i get from an strace of fatrace to files.
Another strange thing is that systemctl list-unit-files fails with "Connection timed out" while being traced, tho i assume that's unrelated and due to smth on systemd's side.
I wonder if anyone can replicate on x86 i haven't been able to try, however I've had confirmation it fails on other arm machines.

I'll try to play with audit/bpf and will update this post if i figure out a way to see which file causes that issue.
Have a good day o/

@martinpitt
Copy link
Owner

I tried to reproduce this with a naïve symlink loop:

--- tests/fatrace-currentmount
+++ tests/fatrace-currentmount
@@ -25,6 +25,12 @@ mv "${TEST_FILE}.2" dest/"${TEST_FILE}.2"
 rm dest/"${TEST_FILE}.2"
 rmdir dest
 
+echo "robustness against ELOOP"
+ln -s link1 link2
+ln -s link2 link1
+ls -lR link1 || true
+rm link1 link2
+

but that works fine. I suppose for system it's not really a symlink loop, but opening with O_NOFOLLOW, and these files ought to be links. Unfortunately I think O_NOFOLLOW can't be done in shell.

martinpitt added a commit that referenced this issue Mar 12, 2021
This does not reproduce issue #2 just yet, but is nevertheless a nice
test to have.
@martinpitt
Copy link
Owner

... but Python to the rescue! I added a test which should model this situation, and it works.

So that's not a reproducer yet, and something more intricate is going on. That said, I think fatrace does not need to be that strict, and it'd be safe to ignore such errors.

@martinpitt
Copy link
Owner

Nevertheless, I made this non-fatal now. Do you have a chance to test current master and letting me know if it's still broken? (I'll also do a new upstream release soon).

@xse
Copy link
Author

xse commented Mar 13, 2021

Do you have a chance to test current master and letting me know if it's still broken? (I'll also do a new upstream release soon).

Yup, it now just warns about it!

2021-03-13 15_30_49-~

Thanks a lot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants