1
0
mirror of https://github.com/systemd/systemd.git synced 2024-10-30 06:25:37 +03:00

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 66a19d85a5:
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.
This commit is contained in:
Zbigniew Jędrzejewski-Szmek 2022-03-15 16:35:47 +01:00
parent 212a24f0bb
commit 40276314af

View File

@ -611,7 +611,7 @@ static int remove_marked_symlinks_fd(
return -ENOMEM;
path_simplify(p);
q = chase_symlinks(p, NULL, CHASE_NONEXISTENT, &dest, NULL);
q = chase_symlinks(p, lp->root_dir, CHASE_NONEXISTENT, &dest, NULL);
if (q == -ENOENT)
continue;
if (q < 0) {