kernel bug or something suse added?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

kernel bug or something suse added?

L A Walsh
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: kernel bug or something suse added?

Adam Tauno Williams
On Tue, 2012-10-02 at 09:37 -0700, Linda Walsh wrote:
> 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.

They do,  permissions presented for links in /proc (and most virtual
filesystems) are bogus.

You can read the "cmdline", which is a better target [I think] for what
you are looking for.


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: kernel bug or something suse added?

L A Walsh
Adam Tauno Williams wrote:
> They do,  permissions presented for links in /proc (and most virtual
> filesystems) are bogus.
----
        :-( !!!!!

        Why bother putting special permission handling code in the
kernel when the fs-attrs could take care of it and allow more
flexibility.


>
> You can read the "cmdline", which is a better target [I think] for what
> you are looking for.
-----
---
        Some yes, sometimes not -- If I really want to know what binary a program
is running and not what it wants to 'tell me' ....I have so many scripts that call
sudo for trivial little things like this -- just because it had to be done some
special way....sigh.


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: kernel bug or something suse added?

Philipp Thomas-3
In reply to this post by L A Walsh
On Tue, 02 Oct 2012 09:37:04 -0700, Linda Walsh <[hidden email]>
wrote:

>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).

Why do you ask here where you'll get next to no reply from the SUSE
developers (with a few exceptions like Lars, Marcus and myself)? You
should have directly asked over on the [hidden email] ml where
I'm sure you would've gotten quick replies from those who know.

Philipp
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: kernel bug or something suse added?

Adam Tauno Williams
In reply to this post by L A Walsh
On Sun, 2012-10-07 at 16:23 -0700, Linda Walsh wrote:
> Adam Tauno Williams wrote:
> > They do,  permissions presented for links in /proc (and most virtual
> > filesystems) are bogus.
> ----
> :-( !!!!!
> Why bother putting special permission handling code in the
> kernel when the fs-attrs could take care of it and allow more
> flexibility.

Eh?   You do realize that permissions works this way on links in most
cases?   Permissions on links are always bogus;  it is the permissions
of the context and the target object which matter, and these are thinks
the file-system in many cases cannot know.

You should experiment with symbolic links.

> > You can read the "cmdline", which is a better target [I think] for what
> > you are looking for.
> -----
> ---
> Some yes, sometimes not -- If I really want to know what binary a program
> is running and not what it wants to 'tell me' ....I have so many scripts that call
> sudo for trivial little things like this -- just because it had to be done some
> special way....sigh.

Yep, security is a pain, that is true.

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]