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

readlink: Behaviour differs from GNU Coreutils when path exists but cannot be read #6688

Open
aidanharris opened this issue Sep 8, 2024 · 1 comment

Comments

@aidanharris
Copy link

Running as a non-root user that does not have permission to read /proc/1/exe (since the init process is started as root):

Expected:

$ readlink -f /proc/1/exe /etc/hosts
/etc/hosts

Actual:

$ readlink -f /proc/1/exe /etc/hosts
/proc/1/exe
/etc/hosts

We do see the error raised correctly when Uutils doesn't canonicalize the path:

$ readlink -v /proc/1/exe /etc/hosts
readlink: /proc/1/exe: Permission denied

But it's returning early instead of processing the rest of the files:

GNU Coreutils

$ readlink -v -e /proc/1/exe /etc/hosts
readlink: /proc/1/exe: Permission denied
/etc/hosts

Running

@samueltardieu
Copy link
Contributor

I wonder whether GNU readlink -f /proc/1/exe /etc/hosts displaying only /etc/hosts is right. The description for -f on https://www.gnu.org/software/coreutils/manual/html_node/readlink-invocation.html#readlink-invocation is:

Activate canonicalize mode. If any component of the file name except the last one is missing or unavailable, readlink produces no output and exits with a nonzero exit code. A trailing slash is ignored.

Aren't all the components of the file name /proc/1/exe except the last one present and available?

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

No branches or pull requests

3 participants