When I su from root to another id I can not anymore list links in /proc/'pid'/ of the original process. This creates a problem when for example running perl as root and switching id (using $>) after which in some circumstances perl tries to start /proc/self/exe which is a link to /usr/bin/perl and fails. Is this a known bug ? Thank you Markus # whoami root # echo $$ 13924 # ls -al /proc/13924 total 0 dr-xr-xr-x 6 root root 0 2008-02-22 21:01 . dr-xr-xr-x 124 root root 0 2008-02-18 20:11 .. dr-xr-xr-x 2 root root 0 2008-02-26 21:48 attr -r-------- 1 root root 0 2008-02-26 21:48 auxv --w------- 1 root root 0 2008-02-26 21:48 clear_refs -r--r--r-- 1 root root 0 2008-02-25 12:18 cmdline -r--r--r-- 1 root root 0 2008-02-26 21:48 cpuset lrwxrwxrwx 1 root root 0 2008-02-26 21:48 cwd -> /home/markus -r-------- 1 root root 0 2008-02-26 21:48 environ lrwxrwxrwx 1 root root 0 2008-02-26 12:16 exe -> /lib/ast/bin/ksh dr-x------ 2 root root 0 2008-02-26 21:48 fd dr-x------ 2 root root 0 2008-02-26 21:48 fdinfo -rw-r--r-- 1 root root 0 2008-02-26 21:48 loginuid -r--r--r-- 1 root root 0 2008-02-26 21:48 maps -rw------- 1 root root 0 2008-02-26 21:48 mem -r--r--r-- 1 root root 0 2008-02-26 21:48 mounts -r-------- 1 root root 0 2008-02-26 21:48 mountstats -rw-r--r-- 1 root root 0 2008-02-26 21:48 oom_adj -r--r--r-- 1 root root 0 2008-02-26 21:48 oom_score lrwxrwxrwx 1 root root 0 2008-02-26 21:48 root -> / -rw------- 1 root root 0 2008-02-26 21:48 seccomp -r--r--r-- 1 root root 0 2008-02-26 21:48 smaps -r--r--r-- 1 root root 0 2008-02-26 21:47 stat -r--r--r-- 1 root root 0 2008-02-26 12:16 statm -r--r--r-- 1 root root 0 2008-02-25 12:18 status dr-xr-xr-x 3 root root 0 2008-02-26 21:48 task -r--r--r-- 1 root root 0 2008-02-26 21:48 wchan # su nobody nobody@Opensuse:/home/markus> ls -al /proc/13924 ls: cannot read symbolic link /proc/13924/cwd: Permission denied ls: cannot read symbolic link /proc/13924/root: Permission denied ls: cannot read symbolic link /proc/13924/exe: Permission denied total 0 dr-xr-xr-x 6 root root 0 2008-02-22 21:01 . dr-xr-xr-x 126 root root 0 2008-02-18 20:11 .. dr-xr-xr-x 2 root root 0 2008-02-26 21:48 attr -r-------- 1 root root 0 2008-02-26 21:48 auxv --w------- 1 root root 0 2008-02-26 21:48 clear_refs -r--r--r-- 1 root root 0 2008-02-25 12:18 cmdline -r--r--r-- 1 root root 0 2008-02-26 21:48 cpuset lrwxrwxrwx 1 root root 0 2008-02-26 21:48 cwd -r-------- 1 root root 0 2008-02-26 21:48 environ lrwxrwxrwx 1 root root 0 2008-02-26 12:16 exe dr-x------ 2 root root 0 2008-02-26 21:48 fd dr-x------ 2 root root 0 2008-02-26 21:48 fdinfo -rw-r--r-- 1 root root 0 2008-02-26 21:48 loginuid -r--r--r-- 1 root root 0 2008-02-26 21:48 maps -rw------- 1 root root 0 2008-02-26 21:48 mem -r--r--r-- 1 root root 0 2008-02-26 21:48 mounts -r-------- 1 root root 0 2008-02-26 21:48 mountstats -rw-r--r-- 1 root root 0 2008-02-26 21:48 oom_adj -r--r--r-- 1 root root 0 2008-02-26 21:48 oom_score lrwxrwxrwx 1 root root 0 2008-02-26 21:48 root -rw------- 1 root root 0 2008-02-26 21:48 seccomp -r--r--r-- 1 root root 0 2008-02-26 21:48 smaps -r--r--r-- 1 root root 0 2008-02-26 21:47 stat -r--r--r-- 1 root root 0 2008-02-26 12:16 statm -r--r--r-- 1 root root 0 2008-02-25 12:18 status dr-xr-xr-x 3 root root 0 2008-02-26 21:48 task -r--r--r-- 1 root root 0 2008-02-26 21:48 wchan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday 26 February 2008 14:54, Markus Moeller wrote:
When I su from root to another id I can not anymore list links in /proc/'pid'/ of the original process. This creates a problem when for example running perl as root and switching id (using $>) after which in some circumstances perl tries to start /proc/self/exe which is a link to /usr/bin/perl and fails.
Is this a known bug ?
It's a known behavior, but by no means a bug! The only way you're going to make this work is by acquiring access (opening a file, e.g.) and by then passing that descriptor across the ID change back to the restricted UID. This is possible when writing in C (and many other languages, including scripting languages). Doing it from the shell is at best a trickier proposition. In particular, while the shell allows much more than the usual ">", "<", "|" operators for, I see no indication (in the man or info page) that su will participate in such machinations. It may simply allow all non-standard descriptors (those other than 0, 1 and 2) to persist after the UID change and the new process is executed, it may, as a security measure, close all but those descriptors. You'll have to experiment.
Thank you Markus
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
That sounds a bit useless that after the su I can access all files in
/proc/'pid'/ and I can list the real file but not the link in /proc/'pid'/
to the real file.
I can't believe that this makes sense and is intended.
Markus
"Randall R Schulz"
On Tuesday 26 February 2008 14:54, Markus Moeller wrote:
When I su from root to another id I can not anymore list links in /proc/'pid'/ of the original process. This creates a problem when for example running perl as root and switching id (using $>) after which in some circumstances perl tries to start /proc/self/exe which is a link to /usr/bin/perl and fails.
Is this a known bug ?
It's a known behavior, but by no means a bug!
The only way you're going to make this work is by acquiring access (opening a file, e.g.) and by then passing that descriptor across the ID change back to the restricted UID.
This is possible when writing in C (and many other languages, including scripting languages). Doing it from the shell is at best a trickier proposition. In particular, while the shell allows much more than the usual ">", "<", "|" operators for, I see no indication (in the man or info page) that su will participate in such machinations. It may simply allow all non-standard descriptors (those other than 0, 1 and 2) to persist after the UID change and the new process is executed, it may, as a security measure, close all but those descriptors.
You'll have to experiment.
Thank you Markus
Randall Schulz
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday 26 February 2008 16:53, Markus Moeller wrote:
That sounds a bit useless that after the su I can access all files in /proc/'pid'/ and I can list the real file but not the link in /proc/'pid'/ to the real file.
The process in question has effective UID 0 / root. How can you argue that any non-root user should be able to access its /proc information? You do realize that the process ID of the shell resulting from the su invocation is not the same as that of the shell through which su was invoked, right?
I can't believe that this makes sense and is intended.
It seems beyond question, to me.
Markus
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2008-02-26 at 17:15 -0800, Randall R Schulz wrote:
It seems beyond question, to me.
It is not so clear. I can list, as root, this (for example): nimrodel:~ # l /proc/105/ ls: cannot read symbolic link /proc/105/exe: No such file or directory total 0 dr-xr-xr-x 6 root root 0 Feb 27 01:47 ./ dr-xr-xr-x 260 root root 0 Feb 21 21:55 ../ dr-xr-xr-x 2 root root 0 Feb 27 02:28 attr/ - -r-------- 1 root root 0 Feb 27 02:28 auxv - --w------- 1 root root 0 Feb 27 02:28 clear_refs - -r--r--r-- 1 root root 0 Feb 27 02:28 cmdline lrwxrwxrwx 1 root root 0 Feb 27 02:28 cwd -> // <===== - -r-------- 1 root root 0 Feb 27 02:28 environ lrwxrwxrwx 1 root root 0 Feb 27 02:28 exe <===== dr-x------ 2 root root 0 Feb 27 02:28 fd/ dr-x------ 2 root root 0 Feb 27 02:28 fdinfo/ - -rw-r--r-- 1 root root 0 Feb 27 02:28 loginuid - -r--r--r-- 1 root root 0 Feb 27 02:28 maps - -rw------- 1 root root 0 Feb 27 02:28 mem - -r--r--r-- 1 root root 0 Feb 27 02:28 mounts - -r-------- 1 root root 0 Feb 27 02:28 mountstats - -rw-r--r-- 1 root root 0 Feb 27 02:28 oom_adj - -r--r--r-- 1 root root 0 Feb 27 02:28 oom_score lrwxrwxrwx 1 root root 0 Feb 27 02:28 root -> // <===== - -rw------- 1 root root 0 Feb 27 02:28 seccomp - -r--r--r-- 1 root root 0 Feb 27 02:28 smaps - -r--r--r-- 1 root root 0 Feb 27 01:47 stat - -r--r--r-- 1 root root 0 Feb 27 01:47 statm - -r--r--r-- 1 root root 0 Feb 27 02:28 status dr-xr-xr-x 3 root root 0 Feb 27 02:28 task/ - -r--r--r-- 1 root root 0 Feb 27 02:28 wchan And I can also list it as user, because "/proc/105/" is owned by root, but is readable by all. With three exception: the symlinks destinations. cer@nimrodel:~> l /proc/105/ ls: cannot read symbolic link /proc/105/cwd: Permission denied ls: cannot read symbolic link /proc/105/root: Permission denied ls: cannot read symbolic link /proc/105/exe: Permission denied total 0 dr-xr-xr-x 6 root root 0 2008-02-27 01:47 ./ dr-xr-xr-x 264 root root 0 2008-02-21 21:55 ../ dr-xr-xr-x 2 root root 0 2008-02-27 02:28 attr/ - -r-------- 1 root root 0 2008-02-27 02:28 auxv - --w------- 1 root root 0 2008-02-27 02:28 clear_refs - -r--r--r-- 1 root root 0 2008-02-27 02:28 cmdline lrwxrwxrwx 1 root root 0 2008-02-27 02:28 cwd <===== - -r-------- 1 root root 0 2008-02-27 02:28 environ lrwxrwxrwx 1 root root 0 2008-02-27 02:28 exe <===== dr-x------ 2 root root 0 2008-02-27 02:28 fd/ dr-x------ 2 root root 0 2008-02-27 02:28 fdinfo/ - -rw-r--r-- 1 root root 0 2008-02-27 02:28 loginuid - -r--r--r-- 1 root root 0 2008-02-27 02:28 maps - -rw------- 1 root root 0 2008-02-27 02:28 mem - -r--r--r-- 1 root root 0 2008-02-27 02:28 mounts - -r-------- 1 root root 0 2008-02-27 02:28 mountstats - -rw-r--r-- 1 root root 0 2008-02-27 02:28 oom_adj - -r--r--r-- 1 root root 0 2008-02-27 02:28 oom_score lrwxrwxrwx 1 root root 0 2008-02-27 02:28 root <===== - -rw------- 1 root root 0 2008-02-27 02:28 seccomp - -r--r--r-- 1 root root 0 2008-02-27 02:28 smaps - -r--r--r-- 1 root root 0 2008-02-27 01:47 stat - -r--r--r-- 1 root root 0 2008-02-27 01:47 statm - -r--r--r-- 1 root root 0 2008-02-27 02:28 status dr-xr-xr-x 3 root root 0 2008-02-27 02:28 task/ - -r--r--r-- 1 root root 0 2008-02-27 02:28 wchan What the user can not read is what the symlink is pointing to, which is "//" - whatever that is. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHxL6ntTMYHG2NR9URAlJxAKCY31KIMdN40Cvyvcugd+9eD0wOHQCfX4pR jkdpXqZhRtHejHT90GX5Z8k= =o910 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday 26 February 2008 17:36, Carlos E. R. wrote:
The Tuesday 2008-02-26 at 17:15 -0800, Randall R Schulz wrote:
It seems beyond question, to me.
It is not so clear.
I can list, as root, this (for example):
Listing the contents of any per-process sub-directory of /proc is permitted to all. In general, things that can be ascertained by an unprivileged user invoking "ls", "ps", "lsof", etc. are accessible. Beyond that, no. I don't see a problem with this. I imagine (though I don't really know) that the kernel developers made a considered determination of exactly what process metadata is and is not accessible by unprivileged users. Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2008-02-26 at 17:56 -0800, Randall R Schulz wrote:
On Tuesday 26 February 2008 17:36, Carlos E. R. wrote:
The Tuesday 2008-02-26 at 17:15 -0800, Randall R Schulz wrote:
It seems beyond question, to me.
It is not so clear.
I can list, as root, this (for example):
Listing the contents of any per-process sub-directory of /proc is permitted to all. In general, things that can be ascertained by an unprivileged user invoking "ls", "ps", "lsof", etc. are accessible. Beyond that, no.
I don't see a problem with this. I imagine (though I don't really know) that the kernel developers made a considered determination of exactly what process metadata is and is not accessible by unprivileged users.
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. What is pointed to by those symlinks is also strange, it is something named "//", and bash prints the first one in blue and the second in black. What file or entity is that? Normally, it seems to mean the root directory of the filesystem... is that restricted? 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. So... why the denial as user, to list the link destination? - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHxNf7tTMYHG2NR9URAifJAJ4l0e6ivj5W/NncByi3uqqvD6dZ3gCcCXgW OtoXWNFsnXgBicIlCqxS3N0= =F7c7 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday 26 February 2008 19:24, Carlos E. R. 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.
What is pointed to by those symlinks is also strange, it is something named "//", and bash prints the first one in blue and the second in black. What file or entity is that? Normally, it seems to mean the root directory of the filesystem... is that restricted?
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 "/"?
So... why the denial as user, to list the link destination?
It's not, unless that destination itself is not readable. Keep in mind that many of the entries in /proc refer to kernel processes. These are not ordinary processes. E.g., at the moment on my system: % ll /proc/1721 ls: cannot read symbolic link /proc/1721/cwd: Permission denied ls: cannot read symbolic link /proc/1721/root: Permission denied ls: cannot read symbolic link /proc/1721/exe: Permission denied total 0 dr-xr-xr-x 2 root root 0 2008-02-26 20:01 attr/ -r-------- 1 root root 0 2008-02-26 20:01 auxv -r--r--r-- 1 root root 0 2008-02-26 17:30 cmdline -r--r--r-- 1 root root 0 2008-02-26 20:01 cpuset lrwxrwxrwx 1 root root 0 2008-02-26 20:01 cwd -r-------- 1 root root 0 2008-02-26 20:01 environ lrwxrwxrwx 1 root root 0 2008-02-26 20:01 exe dr-x------ 2 root root 0 2008-02-26 20:01 fd/ -rw-r--r-- 1 root root 0 2008-02-26 20:01 loginuid -r--r--r-- 1 root root 0 2008-02-26 20:01 maps -rw------- 1 root root 0 2008-02-26 20:01 mem -r--r--r-- 1 root root 0 2008-02-26 20:01 mounts -rw-r--r-- 1 root root 0 2008-02-26 20:01 oom_adj -r--r--r-- 1 root root 0 2008-02-26 20:01 oom_score lrwxrwxrwx 1 root root 0 2008-02-26 20:01 root -rw------- 1 root root 0 2008-02-26 20:01 seccomp -r--r--r-- 1 root root 0 2008-02-26 17:30 stat -r--r--r-- 1 root root 0 2008-02-26 14:30 statm -r--r--r-- 1 root root 0 2008-02-26 17:01 status dr-xr-xr-x 3 root root 0 2008-02-26 20:01 task/ -r--r--r-- 1 root root 0 2008-02-26 20:01 wchan % ps lwww 1721 F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 1 0 1721 9 16 0 0 0 pdflus S ? 0:02 [pdflush] There is no (ordinary) program named "pdflush", it's a pseudo program created by the kernel to handle dirty page flushing. It does not really have a current working directory (cwd), a root directory or an executable (it executes kernel code), so those symlinks cannot meaningfully be resolved.
-- Cheers, Carlos E. R.
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----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
Markus Moeller wrote:
When I su from root to another id I can not anymore list links in /proc/'pid'/ of the original process. This creates a problem when for example running perl as root and switching id (using $>) after which in some circumstances perl tries to start /proc/self/exe which is a link to /usr/bin/perl and fails.
Is this a known bug ?
Basic security violation. The new, forked-off process is not root. And don't trust the permisssions on symbolic links.
Thank you Markus
# whoami root # echo $$ 13924 # ls -al /proc/13924 total 0 dr-xr-xr-x 6 root root 0 2008-02-22 21:01 . dr-xr-xr-x 124 root root 0 2008-02-18 20:11 .. dr-xr-xr-x 2 root root 0 2008-02-26 21:48 attr -r-------- 1 root root 0 2008-02-26 21:48 auxv --w------- 1 root root 0 2008-02-26 21:48 clear_refs -r--r--r-- 1 root root 0 2008-02-25 12:18 cmdline -r--r--r-- 1 root root 0 2008-02-26 21:48 cpuset lrwxrwxrwx 1 root root 0 2008-02-26 21:48 cwd -> /home/markus -r-------- 1 root root 0 2008-02-26 21:48 environ lrwxrwxrwx 1 root root 0 2008-02-26 12:16 exe -> /lib/ast/bin/ksh dr-x------ 2 root root 0 2008-02-26 21:48 fd dr-x------ 2 root root 0 2008-02-26 21:48 fdinfo -rw-r--r-- 1 root root 0 2008-02-26 21:48 loginuid -r--r--r-- 1 root root 0 2008-02-26 21:48 maps -rw------- 1 root root 0 2008-02-26 21:48 mem -r--r--r-- 1 root root 0 2008-02-26 21:48 mounts -r-------- 1 root root 0 2008-02-26 21:48 mountstats -rw-r--r-- 1 root root 0 2008-02-26 21:48 oom_adj -r--r--r-- 1 root root 0 2008-02-26 21:48 oom_score lrwxrwxrwx 1 root root 0 2008-02-26 21:48 root -> / -rw------- 1 root root 0 2008-02-26 21:48 seccomp -r--r--r-- 1 root root 0 2008-02-26 21:48 smaps -r--r--r-- 1 root root 0 2008-02-26 21:47 stat -r--r--r-- 1 root root 0 2008-02-26 12:16 statm -r--r--r-- 1 root root 0 2008-02-25 12:18 status dr-xr-xr-x 3 root root 0 2008-02-26 21:48 task -r--r--r-- 1 root root 0 2008-02-26 21:48 wchan # su nobody nobody@Opensuse:/home/markus> ls -al /proc/13924 ls: cannot read symbolic link /proc/13924/cwd: Permission denied ls: cannot read symbolic link /proc/13924/root: Permission denied ls: cannot read symbolic link /proc/13924/exe: Permission denied total 0 dr-xr-xr-x 6 root root 0 2008-02-22 21:01 . dr-xr-xr-x 126 root root 0 2008-02-18 20:11 .. dr-xr-xr-x 2 root root 0 2008-02-26 21:48 attr -r-------- 1 root root 0 2008-02-26 21:48 auxv --w------- 1 root root 0 2008-02-26 21:48 clear_refs -r--r--r-- 1 root root 0 2008-02-25 12:18 cmdline -r--r--r-- 1 root root 0 2008-02-26 21:48 cpuset lrwxrwxrwx 1 root root 0 2008-02-26 21:48 cwd -r-------- 1 root root 0 2008-02-26 21:48 environ lrwxrwxrwx 1 root root 0 2008-02-26 12:16 exe dr-x------ 2 root root 0 2008-02-26 21:48 fd dr-x------ 2 root root 0 2008-02-26 21:48 fdinfo -rw-r--r-- 1 root root 0 2008-02-26 21:48 loginuid -r--r--r-- 1 root root 0 2008-02-26 21:48 maps -rw------- 1 root root 0 2008-02-26 21:48 mem -r--r--r-- 1 root root 0 2008-02-26 21:48 mounts -r-------- 1 root root 0 2008-02-26 21:48 mountstats -rw-r--r-- 1 root root 0 2008-02-26 21:48 oom_adj -r--r--r-- 1 root root 0 2008-02-26 21:48 oom_score lrwxrwxrwx 1 root root 0 2008-02-26 21:48 root -rw------- 1 root root 0 2008-02-26 21:48 seccomp -r--r--r-- 1 root root 0 2008-02-26 21:48 smaps -r--r--r-- 1 root root 0 2008-02-26 21:47 stat -r--r--r-- 1 root root 0 2008-02-26 12:16 statm -r--r--r-- 1 root root 0 2008-02-25 12:18 status dr-xr-xr-x 3 root root 0 2008-02-26 21:48 task -r--r--r-- 1 root root 0 2008-02-26 21:48 wchan
-- ARK -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
"The Magic Nose Goblin"
Markus Moeller wrote:
When I su from root to another id I can not anymore list links in /proc/'pid'/ of the original process. This creates a problem when for example running perl as root and switching id (using $>) after which in some circumstances perl tries to start /proc/self/exe which is a link to /usr/bin/perl and fails.
I didn't notice this before, but it doesn't depend on su. A normal user can not list links in /proc/`pid' .
Is this a known bug ?
Basic security violation.
I disagree the file permissions allow it.
The new, forked-off process is not root.
As mentioned above it is valid for any non root process/user, not only a forked process.
And don't trust the permisssions on symbolic links.
That is irrelevant. There seems to be an overwriting control in the kernel for the proc filesystem, which I think is not inline with the correct behaviour.
Thank you Markus
# whoami root # echo $$ 13924 # ls -al /proc/13924 total 0 dr-xr-xr-x 6 root root 0 2008-02-22 21:01 . dr-xr-xr-x 124 root root 0 2008-02-18 20:11 .. dr-xr-xr-x 2 root root 0 2008-02-26 21:48 attr -r-------- 1 root root 0 2008-02-26 21:48 auxv --w------- 1 root root 0 2008-02-26 21:48 clear_refs -r--r--r-- 1 root root 0 2008-02-25 12:18 cmdline -r--r--r-- 1 root root 0 2008-02-26 21:48 cpuset lrwxrwxrwx 1 root root 0 2008-02-26 21:48 cwd -> /home/markus -r-------- 1 root root 0 2008-02-26 21:48 environ lrwxrwxrwx 1 root root 0 2008-02-26 12:16 exe -> /lib/ast/bin/ksh dr-x------ 2 root root 0 2008-02-26 21:48 fd dr-x------ 2 root root 0 2008-02-26 21:48 fdinfo -rw-r--r-- 1 root root 0 2008-02-26 21:48 loginuid -r--r--r-- 1 root root 0 2008-02-26 21:48 maps -rw------- 1 root root 0 2008-02-26 21:48 mem -r--r--r-- 1 root root 0 2008-02-26 21:48 mounts -r-------- 1 root root 0 2008-02-26 21:48 mountstats -rw-r--r-- 1 root root 0 2008-02-26 21:48 oom_adj -r--r--r-- 1 root root 0 2008-02-26 21:48 oom_score lrwxrwxrwx 1 root root 0 2008-02-26 21:48 root -> / -rw------- 1 root root 0 2008-02-26 21:48 seccomp -r--r--r-- 1 root root 0 2008-02-26 21:48 smaps -r--r--r-- 1 root root 0 2008-02-26 21:47 stat -r--r--r-- 1 root root 0 2008-02-26 12:16 statm -r--r--r-- 1 root root 0 2008-02-25 12:18 status dr-xr-xr-x 3 root root 0 2008-02-26 21:48 task -r--r--r-- 1 root root 0 2008-02-26 21:48 wchan # su nobody nobody@Opensuse:/home/markus> ls -al /proc/13924 ls: cannot read symbolic link /proc/13924/cwd: Permission denied ls: cannot read symbolic link /proc/13924/root: Permission denied ls: cannot read symbolic link /proc/13924/exe: Permission denied total 0 dr-xr-xr-x 6 root root 0 2008-02-22 21:01 . dr-xr-xr-x 126 root root 0 2008-02-18 20:11 .. dr-xr-xr-x 2 root root 0 2008-02-26 21:48 attr -r-------- 1 root root 0 2008-02-26 21:48 auxv --w------- 1 root root 0 2008-02-26 21:48 clear_refs -r--r--r-- 1 root root 0 2008-02-25 12:18 cmdline -r--r--r-- 1 root root 0 2008-02-26 21:48 cpuset lrwxrwxrwx 1 root root 0 2008-02-26 21:48 cwd -r-------- 1 root root 0 2008-02-26 21:48 environ lrwxrwxrwx 1 root root 0 2008-02-26 12:16 exe dr-x------ 2 root root 0 2008-02-26 21:48 fd dr-x------ 2 root root 0 2008-02-26 21:48 fdinfo -rw-r--r-- 1 root root 0 2008-02-26 21:48 loginuid -r--r--r-- 1 root root 0 2008-02-26 21:48 maps -rw------- 1 root root 0 2008-02-26 21:48 mem -r--r--r-- 1 root root 0 2008-02-26 21:48 mounts -r-------- 1 root root 0 2008-02-26 21:48 mountstats -rw-r--r-- 1 root root 0 2008-02-26 21:48 oom_adj -r--r--r-- 1 root root 0 2008-02-26 21:48 oom_score lrwxrwxrwx 1 root root 0 2008-02-26 21:48 root -rw------- 1 root root 0 2008-02-26 21:48 seccomp -r--r--r-- 1 root root 0 2008-02-26 21:48 smaps -r--r--r-- 1 root root 0 2008-02-26 21:47 stat -r--r--r-- 1 root root 0 2008-02-26 12:16 statm -r--r--r-- 1 root root 0 2008-02-25 12:18 status dr-xr-xr-x 3 root root 0 2008-02-26 21:48 task -r--r--r-- 1 root root 0 2008-02-26 21:48 wchan
-- ARK
Markus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (4)
-
Carlos E. R.
-
Markus Moeller
-
Randall R Schulz
-
The Magic Nose Goblin