From: "linda w." <lkml@tlinx.org>
To: "'Albert Cahalan'" <albert@users.sourceforge.net>,
"'linux-kernel'" <linux-kernel@vger.kernel.org>, <lkml@tlinx.org>
Subject: RE: reading links in proc - permission denied
Date: Thu, 5 Jun 2003 22:45:21 -0700 [thread overview]
Message-ID: <000101c32bee$d159f410$1403a8c0@sc.tlinx.org> (raw)
In-Reply-To: <1054865029.22103.6995.camel@cube>
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
> 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?
> 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.
---
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....
>
> > 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?
> 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
next prev parent reply other threads:[~2003-06-06 5:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-06 2:03 Albert Cahalan
2003-06-06 5:45 ` linda w. [this message]
[not found] <200306141905.h5EJ57mE024740@leija.fmi.fi>
2003-06-14 20:55 ` linda w.
2003-06-14 21:10 ` Ray Olszewski
2003-06-14 22:09 ` root
-- strict thread matches above, loose matches on Subject: below --
2003-06-05 3:12 linda w.
2003-06-04 18:59 linda w.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='000101c32bee$d159f410$1403a8c0@sc.tlinx.org' \
--to=lkml@tlinx.org \
--cc=albert@users.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®