All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Jeff Layton <jlayton@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	pavel@ucw.cz
Subject: Re: [PATCH] procfs: make /proc style symlinks behave like "normal" symlinks
Date: Thu, 19 Nov 2009 10:57:08 -0800	[thread overview]
Message-ID: <m1skca2vi3.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <20091119132833.30bc93a4@barsoom.rdu.redhat.com> (Jeff Layton's message of "Thu\, 19 Nov 2009 13\:28\:33 -0500")

Jeff Layton <jlayton@redhat.com> writes:

> On Thu, 19 Nov 2009 09:07:16 -0800
> ebiederm@xmission.com (Eric W. Biederman) wrote:
>
>> 
>> Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>> 
>> This is broken.  If the referenced file is in a different mount namespace
>> the path returned could point to a completely different path in your
>> own mount namespace.  Even in your own mount namespace this makes the
>> proc symlinks racy and not guaranteed to return the file of interest.
>> 
>> I don't see any hope of this approach ever working.
>> 
>> Eric
>> 
>
> Then is proc_pid_readlink broken in the same way?

proc_pid_readlink has the same deficiencies.  The race is fundamental
to all readlink operations, the difference is that for normal symlinks
it is a don't care, and for proc it is incorrect behavior if you follow
the symlink to the wrong file.   If you are dealing with a file in a
different namespace or a socket what you get back doesn't actually
work as a file in your local namespace but that is the best we can do
with a pathname, and if you know the context of what is going on readlink
is still useful.

Adding all of the short comings to followlink that readlink has is a problem,
especially as followlink does much better now.

At a practical level I think your changes are much easier to exploit than
Pavels contrived example.

I really don't have any problems with your first patch to proc to add the
missing revalidate.

Eric

  reply	other threads:[~2009-11-19 18:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-19 13:44 [PATCH] procfs: make /proc style symlinks behave like "normal" symlinks Jeff Layton
2009-11-19 17:07 ` Eric W. Biederman
2009-11-19 18:28   ` Jeff Layton
2009-11-19 18:57     ` Eric W. Biederman [this message]
2009-11-19 19:35       ` Jeff Layton
2009-11-19 21:31         ` Eric W. Biederman
2009-11-19 21:39         ` Pavel Machek
2009-11-19 21:56           ` Eric W. Biederman
2009-11-19 22:30             ` Pavel Machek
2009-11-20  9:31           ` Miklos Szeredi
2009-11-20  9:51             ` Pavel Machek

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=m1skca2vi3.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=jlayton@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /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.