reading links in proc - permission denied
Quoted 5 lines
I'm misunderstanding something about links in proc.
I thought 'ps', 'top' et al used /proc to display
processes, command lines, etc.
Quoted 8 lines
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)"
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 3 lines
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.
Quoted 4 lines
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
Thanks for your answer, I guess not many people understand some of these things.
So...if I'm not allowed to read the link, wouldn't it be a bug for the permissions to claim it is group/other readable?
lrwxrwxrwx 1 root root 0 Jun 5 22:29 /proc/2/exe
Exactly "what" is determining the permissions on the ability to read the link if not the file permissions?
Should it read?
lrwx------ 1 root root 0 Jun 5 22:29 /proc/2/exe
Quoted 8 lines
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)"
---
Yeah...it could be a mess, but wouldn't you be guaranteed that it
would be a zero terminated string?
Quoted 5 lines
The restricted permission on
/proc/*/exeis kind of dumb though, considering that/proc/*/mapsis 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.
---
Well that "could" be handled by an attempt to stat the target in
the user's context and see if the file can be reached through the directory chain, but hey, what's the point of consistency, anyway? "Isn't it consistency is the foolish hobgoblin of small minds?" Er, something like that....
Quoted 6 lines
Quoted 4 lines
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 if the process could muck with it, like path, then if it was
able to switch back to ROOT, wouldn't that be a security risk?
Quoted 7 lines
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
---
some more primitive unix clones (cygwin for example) don't have such luxuries....now that I mention it....it doesn't have an 'exe' entry under proc either...*snort*.
Nevermind....:-)
-l