Mailinglist Archive: opensuse (924 mails)

< Previous Next >
[opensuse] kernel bug or something suse added?
I was just looking in /proc/<process> as 'self' non-root.
I was looking at the schedtool and the scheduling algorithm in place for each process:

cd /proc
for i in [0-9]*;do
schedtool $i

Which ran fine except it didn't tell me what processes .. and numbers weren't really what I wanted, so I thought why not list the exe. I thought to
add "ls -L $i" in the above to each line -- but get permission probs:

ls: cannot read symbolic link 1/exe: Permission denied

Running as root, of course, no prob.

This is 'normal' behavior as I have come to expect, BUT,
in paying attention to the permissions on the symlink:

lrwxrwxrwx 1 root root 0 Oct 2 09:10 exe

The permissions don't agree with what the kernel is doing.

I'd expect to see something similar to the permissions on the dir
itself like:

dr-xr-xr-x 8 root root 0 Oct 2 03:43 ./

But if hiding the executable name was really wanted, then I'd expect to
see something like

lrwx------ 1 root root 0 Oct 2 09:10 exe
lrwxr-x--- 1 root root 0 Oct 2 09:10 exe
lrwxrwx--- 1 root root 0 Oct 2 09:10 exe

(of course I find it unlikely that root could actually write to this var...
maybe it can and immediately that process would start a new program, but
I sorta doubt it.

Now just to be clear -- 'exe' is pointing (in my case) to

lrwxrwxrwx 1 0 Oct 2 09:22 1/exe -> /sbin/sysvinit
and as a normal user I can do an "ls" on that file:
-rwxr-xr-x 1 47200 Jun 21 00:49 /sbin/sysvinit

So it is not the permissions on the target file that are causing the access
denied message -- it's the ability to read the link which claims I should be
able to do so:

*** Shouldn't the permissions in the link reflect the permissions being
given? ***

I'd surmise there is special code that ignores the listed permissions and
creates it's own permission/access code to that information and it's hard
coded to only allow root or the process owner. But WHY? Why not use the
permissions on the links in /proc to achieve the same effect?? Is the special
code *Needed*? Wouldn't relying on the general access mechanism work just as

Also, it would be easier if access was controlled in the DACL, or umask, to
diverse security policies -- like enabling someone to look at what executable someone
is running without having to have root access -- which would seem like a good

So I'm guessing this is a bug in the kernel and that suse didn't add
code to create this inconsistency -- but thought i'd ask if
1) anyone knew if opensuse changed the defaults in this area
2) anyone knew why it was this way (why inconsistent -- why 2 separate access
mechanisms, one of which (the standard perms DACL) is ignored
3) why this particular bit of information was protected this way when things
like 'cmdline' is not? Or why mountinfo+mounts but not mountstats???

Why should memory, scheduler cgroup, limits latency (and a bunch of others) be readable
but not io statistics and mount statistics??? (as well as the links 'cwd,exe,root')..

It looks a bit random? Does someone know why or how these things got this way?
Should they stay? Why should top be able to give memory &cpu stats to normal
but not io stats? (for example).

Comments appreciated before I go off and write up a kernel bug on this..

To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >