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 done --- 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 or lrwxr-x--- 1 root root 0 Oct 2 09:10 exe or 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 well? Also, it would be easier if access was controlled in the DACL, or umask, to allow 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 thing. 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 users, 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@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org