-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2008-02-26 at 20:12 -0800, Randall R Schulz wrote:
I don't see a problem with this. ...
I don't know if it is a problem or not. Only... strange.
It is not the typical behaviour of ls: if you have access to a directory, you can list it, and the symlinks and what the symlinks point to - I think. What you may not be able to do is to open files in that directory.
You have to sort out the permissions. Read access to a directory only allows you to enumerate its contents. You have to have execute permission to the directory to resolve its contents in any other way. And symbolic links can fail to resolve in any case.
It is not a permission thing. The directory is "dr-xr-xr-x", so any user can access it.
The target of the symlink is / and "ls" was invoked with the -F flag. Thus the name printed appears as "//".
If I use "mc" to navigate there, as root, it says that "root" and "cwd" point in fact to the "/" directory of the filesystem. What can be restricted about that? I do have permissions as user to list the "/" directory.
I don't know what "mc" does when it cannot resolve a symlink. Perhaps it just shows "/"?
No, no. If I list this directory for the PID of root's bash session as root I see: nimrodel:/proc/9429 # l /proc/9429 total 0 dr-xr-xr-x 6 root root 0 Feb 27 10:54 ./ dr-xr-xr-x 257 root root 0 Feb 21 21:55 ../ dr-xr-xr-x 2 root root 0 Feb 27 11:37 attr/ ... lrwxrwxrwx 1 root root 0 Feb 27 11:37 cwd -> // lrwxrwxrwx 1 root root 0 Feb 27 10:54 exe -> /bin/bash* lrwxrwxrwx 1 root root 0 Feb 27 11:37 root -> // ... But as user those same symlinks fail to resolve: cer@nimrodel:~> l /proc/9429 ls: cannot read symbolic link /proc/9429/cwd: Permission denied ls: cannot read symbolic link /proc/9429/root: Permission denied ls: cannot read symbolic link /proc/9429/exe: Permission denied total 0 dr-xr-xr-x 6 root root 0 2008-02-27 10:54 ./ dr-xr-xr-x 259 root root 0 2008-02-21 21:55 ../ dr-xr-xr-x 2 root root 0 2008-02-27 11:37 attr/ -r-------- 1 root root 0 2008-02-27 11:37 auxv ... If I create a replica of the above: nimrodel:/tmp/ppp # nimrodel:/tmp/ppp # l total 36 dr-xr-xr-x 3 root root 4096 Feb 27 11:43 ./ drwxrwxrwt 112 root root 28672 Feb 27 11:45 ../ dr-xr-xr-x 2 root root 4096 Feb 27 11:44 attr/ lrwxrwxrwx 1 root root 1 Feb 27 11:43 cwd -> // lrwxrwxrwx 1 root root 9 Feb 27 11:43 exe -> /bin/bash* lrwxrwxrwx 1 root root 1 Feb 27 11:43 root -> // I can read it again as user: cer@nimrodel:~> l /tmp/ppp total 36 dr-xr-xr-x 3 root root 4096 2008-02-27 11:43 ./ drwxrwxrwt 112 root root 28672 2008-02-27 11:45 ../ dr-xr-xr-x 2 root root 4096 2008-02-27 11:44 attr/ lrwxrwxrwx 1 root root 1 2008-02-27 11:43 cwd -> // lrwxrwxrwx 1 root root 9 2008-02-27 11:43 exe -> /bin/bash* lrwxrwxrwx 1 root root 1 2008-02-27 11:43 root -> // with no problem at all. There is nothing "secret" about those symlinks. One is the bash binary (in this case), the other two are the filesystem root directory. It is not a permission thing of the proc/PID directory. The denial must implemented somewhere in the kernel thing providing that pseudo filesystem, for reasons not very clear. If, as you mention, the process is a kernel thing, then the "exe" symlink points nowhere. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHxUGytTMYHG2NR9URAlpaAKCNQ2z09h/hQlIRJBkuR8gzbVpDigCfexz2 /0csd67uif4CxLGSdFAo8XU= =ewRV -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org