All of lore.kernel.org
 help / color / mirror / Atom feed
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...


      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 2.6.13: can kill X server but readlink of /proc/<pid>/exe et. al. says EACCES. feature? 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.