All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Trond Myklebust <trond.myklebust@primarydata.com>
Cc: Benjamin Coddington <bcodding@redhat.com>,
	"Andrew J. Romero" <romero@fnal.gov>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"Michael K. Rosier" <mrosier@fnal.gov>,
	Briant S Lawson <blawson@fnal.gov>,
	Joseph W Klemencic <jklemenc@fnal.gov>,
	Lynn A Garren <garren@fnal.gov>,
	Jeff Layton <jlayton@primarydata.com>
Subject: Re: Linux NFSv4 security issue: client presents wrong user's credentials to NFS server
Date: Tue, 7 Oct 2014 10:29:34 -0400	[thread overview]
Message-ID: <20141007142934.GA25677@fieldses.org> (raw)
In-Reply-To: <CAHQdGtRF+_yJKiWHKTmZZ1gx3Y9LsSk62EtZNjkZFPOr5u=vYw@mail.gmail.com>

On Tue, Oct 07, 2014 at 09:36:12AM -0400, Trond Myklebust wrote:
> The problem with the request key interface is that it is completely
> broken when applied to containers, since it only runs in the global
> init namespace context. Fixing that is a non-trivial exercise; you'd
> have to not only carry a full namespace context with the RPC
> credential, but also somehow apply it to the upcall thread.

This one's really keeping me up at night.  Mainly because of the server
reboot recovery stuff.  The client v4 idmapping has this problem too,
doesn't it?

How are we going to decide if the user-helper containerization is doable
or if it's just a hopeless case?

Jeff seems optimistic about fixing it, and that'd be great, but if it's
not going to happen then we need to give up and use daemons for this
stuff.

--b.

  reply	other threads:[~2014-10-07 14:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-07  2:47 Linux NFSv4 security issue: client presents wrong user's credentials to NFS server Andrew J. Romero
2014-10-07 13:10 ` Benjamin Coddington
2014-10-07 13:36   ` Trond Myklebust
2014-10-07 14:29     ` J. Bruce Fields [this message]
2014-10-08 19:39     ` Benjamin Coddington
2014-10-08 19:47       ` Trond Myklebust

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=20141007142934.GA25677@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=bcodding@redhat.com \
    --cc=blawson@fnal.gov \
    --cc=garren@fnal.gov \
    --cc=jklemenc@fnal.gov \
    --cc=jlayton@primarydata.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=mrosier@fnal.gov \
    --cc=romero@fnal.gov \
    --cc=trond.myklebust@primarydata.com \
    /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.