Re: reading links in proc - permission denied

[Albert Cahalan]

> I'm misunderstanding something about links in proc.
>
> I thought 'ps', 'top' et al used /proc to display
> processes, command lines, etc.
>
> Since neither ps nor top are suid root, they are
> running with my uid permissions.
>
> However, if I do "ls -l" on /proc/<number>/exe, I get a
>
> "ls: cannot read symbolic link /proc/16714/exe: Permission denied"
>
> message.

All true, but you're assuming /proc/*/exe is used.
Nope. There is a parser for /proc/*/status and
/proc/*/stat, plus /proc/*/cmdline for args.

Please don't try this yourself. I can spot bugs
in almost any parser for these files. Consider
processes with names like these:

"\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
":-) 1 2 3 4 5 6"
"foo Pid: 42"
"x State: Z (z)"

> Now the process is owned by 'named', but the entries in
> diriectory are owned by root (is that right/logical?), thus:

It makes sense in general. An app running on behalf
of a user (with a non-root UID) may still contain
secret data gained via the prior UID.

It would be nice if the app could declare itself
free of this problem.

The restricted permission on /proc/*/exe is kind of
dumb though, considering that /proc/*/maps is wide open.
Ability to follow the link might need to be restricted,
since the link is (was?) magic. It acts somewhat like
a hard link, bypassing permissions along the path.

> Purely from a 'cleanliness' standpoint, is the
> environment owned by the user-id, or is it a common
> piece of public, kernel (root) owned data?

It's swappable. The process can muck with it.

> So why can't I follow the link of 'exe' to see what image the
> process is executing?  Programs like 'ps' and 'top' seem to not
> have this difficulty.

I wish.

> Thanks for any insights...I'm trying to write a simple script
> looking for a running process (by looking at what 'exe' is   
> pointing to).  I would find it kludgey to achieve the objective
> by running 'ps' and doing appropriate filtering. 

There's nothing wrong with parsing ps output. Be sure to split
on whitespace, and not by character position. You can also use
pgrep or pidof. For example:

ps -C foo -opid=
pgrep -u root sshd
pidof something