On Tue, Dec 30, 2014 at 02:02:32PM +0100, Christian Hesse wrote:
Christian Hesse <list@eworm.de> on Tue, 2014/12/30 13:42:
Mohammad_AlSaleh <ce.mohammad.alsaleh@gmail.com> on Tue, 2014/12/30 14:36:
Hello.
I just came across some weird behavior.
A small testcase:
cd /tmp # should be tmpfs touch tfile ln -s tfile tlink cat tlink
When cat executes, it returns with success(0). But, if cat is executed as root, it fails with a permission denied error.
What's really happening is, the open() syscall fails with EACCESS when the file is a symlink in a tmpfs-mounted dir. But only fails when run as root!
I'm assuming this is a bug. Can anyone confirm it?
This is expected as /tmp has the sticky bit set.
https://wiki.ubuntu.com/Security/Features#Symlink_restrictions
As this was related to Ubuntu and pathes do not match... You can control the behavior via proc filesystem:
/proc/sys/fs/protected_symlinks
Or simply use sysctl:
sysctl -w fs.protected_symlinks=0
If you want to make this permanent add the entry to configuration file in /etc/sysctl.d/.
Thanks again. Now that I understand what's going on, there is no need to change the default behavior. FWIW, I came across this behavior when I was testing a temporary local repository. pacman failed to fetch repo_name.db which is a symlink created by repo-add. libcurl accesses the filesystem directly with file:// URLs. So, it tried to open repo_name.db for reading and failed.
-- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Chris get my mail address: */=0;b=c[a++];) putchar(b-1/(/* gcc -o sig sig.c && ./sig */b/42*2-3)*42);}