From: viro@ZenIV.linux.org.uk
To: Frank van Maarseveen <frankvm@frankvm.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.6.13: can kill X server but readlink of /proc/<pid>/exe et. al. says EACCES. feature?
Date: Tue, 6 Sep 2005 20:02:55 +0100 [thread overview]
Message-ID: <20050906190255.GB5155@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20050906185041.GA728@janus>
On Tue, Sep 06, 2005 at 08:50:41PM +0200, Frank van Maarseveen wrote:
> On Tue, Sep 06, 2005 at 06:57:37PM +0100, viro@ZenIV.linux.org.uk wrote:
> > On Tue, Sep 06, 2005 at 07:53:49PM +0200, Frank van Maarseveen wrote:
> > > While I have access to /proc/<pid>, readlink fails with EACCES on
> > >
> > > /proc/<pid>/exe
> > > /proc/<pid>/cwd
> > > /proc/<pid>/root
> > >
> > > even when I own <pid> though it runs with a different effective/saved/fs
> > > uid such as the X server. This is a bit uncomfortable and doesn't
> > > seem right.
> > >
> > > Or is this to make /proc mounting inside a chroot jail safe?
> >
> > suid-root task does chdir() to place you shouldn't be able to access.
> > You do cd /proc/<pid>/cwd and get there anyway. Bad Things Happen...
>
> Ok, but being able to do readlink() does not mean that one can chdir(),
> usually.
follow_link on these guys does _not_ traverse parent directories. So chdir()
checks are more relaxed that way. Even if we made checks on readlink work
differently, we would still get an information leak - e.g. if task had
created a directory with pathname derived from sensitive data and did chdir
there. Being able to kill a task != being able to see pieces of its state...
prev parent reply other threads:[~2005-09-06 19:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-06 17:53 Frank van Maarseveen
2005-09-06 17:57 ` viro
2005-09-06 18:50 ` Frank van Maarseveen
2005-09-06 19:02 ` viro [this message]
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=20050906190255.GB5155@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=frankvm@frankvm.com \
--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®