]> git.ipfire.org Git - thirdparty/systemd.git/commit
shared/install: do not try to resolve symlinks outside of root directory
authorZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Tue, 15 Mar 2022 15:35:47 +0000 (16:35 +0100)
committerZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Tue, 29 Mar 2022 14:17:56 +0000 (16:17 +0200)
commit40276314afc4fb5c35c6b3da3e6185af6ed3886b
tree79ee47bf9357e0770ca0a9a4f96f100b4237a2e2
parent212a24f0bbe4c54183d3b0ad9579a995007e29a8
shared/install: do not try to resolve symlinks outside of root directory

I linked a file as root, so I had a symlink /root/test.service ← /etc/systemd/system/test.service.
To my surpise, when running test-systemctl-enable, it failed with a cryptic EACCES.
The previous commit made the logs a bit better. Strace shows that we
were trying to follow the symlink without taking --root into account.

It seems that this bug was introduced in 66a19d85a533b15ed32f4066ec880b5a8c06babd:
before it, we'd do readlink_malloc(), which returned a path relative to root. But
we only used that path for checking if the path is in remove_symlinks_to set, which
contains relative paths. So if the path was relative, we'd get a false-negative
answer, but we didn't go outside of the root. (We need to canonicalize the symlink
to get a consistent answer.) But after 66a19 we use chase_symlinks(), without taking
root into account which is completely bogus.
src/shared/install.c