mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
	containers@lists.osdl.org, Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH 4/8] user ns: hook permission
Date: Wed, 24 Jan 2007 10:06:03 -0700	[thread overview]
Message-ID: <m14pqg2w3o.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20061219230051.GE25904@sergelap.austin.ibm.com> (Serge E. Hallyn's message of "Tue, 19 Dec 2006 17:00:51 -0600")

"Serge E. Hallyn" <serue@us.ibm.com> writes:

> From: Serge E. Hallyn <serue@us.ibm.com>
> Subject: [PATCH 4/8] user ns: hook permission
>
> Hook permission to check vfsmnt->user_ns against current.

This looks wrong on several levels.
- This should ultimately be inside generic_permission instead of
  permission as there are some distributed filesystems that know how to cope with
  multiple mount namespaces simultaneous.

- As implemented the test is not what I would expect.  I would
  expect comparisons of uid X == uid Y and gid X == gid Y to
  be replaced by comparing the tuples of uid namesspace and uid.
  Which would allow access to world readable/writeable files,
  and it would allow users with CAP_DAC_OVERRIDE to be able to access
  everything.

All we are really saying as I understand a user namespace is that 
instead of uid's uniquely identifying a user the pair the pair uidns,
uid is uniquely identifies a user.

Because you didn't pick what I would consider the obvious choice
you now need an extra mount flag to disable the uid namespace all
together, so you can transition through the intermediate uid namespace
state.  That really feels wrong.

All mounts should have an associated uid namespace and the only
way you should be able to ignore that is to access filesystems
that can cope with multiple uid namespaces simultaneously.

Eric

  reply	other threads:[~2007-01-24 17:06 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-19 22:59 [PATCH 0/8] user namespace: Introduction Serge E. Hallyn
2006-12-19 22:59 ` [PATCH 1/8] nsproxy: externalizes exit_task_namespaces Serge E. Hallyn
2006-12-19 23:00 ` [PATCH 2/8] user ns: add the framework Serge E. Hallyn
2006-12-19 23:00 ` [PATCH 3/8] user ns: add user_namespace ptr to vfsmount Serge E. Hallyn
2006-12-19 23:00 ` [PATCH 4/8] user ns: hook permission Serge E. Hallyn
2007-01-24 17:06   ` Eric W. Biederman [this message]
2007-01-24 19:06     ` Serge E. Hallyn
2006-12-19 23:01 ` [PATCH 5/8] user ns: prepare copy_tree, copy_mnt, and their callers to handle errs Serge E. Hallyn
2006-12-19 23:01 ` [PATCH 6/8] user ns: implement shared mounts Serge E. Hallyn
2006-12-19 23:01 ` [PATCH 7/8] user ns: handle file sigio Serge E. Hallyn
2007-01-24 17:23   ` Eric W. Biederman
2007-01-24 18:58     ` Serge E. Hallyn
2007-01-25  8:12       ` Andrew Morton
2007-01-25 15:32         ` Serge E. Hallyn
2007-01-26  5:38           ` Serge E. Hallyn
2007-01-26  6:09             ` Andrew Morton
2006-12-19 23:01 ` [PATCH 8/8] user ns: implement user ns unshare Serge E. Hallyn

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=m14pqg2w3o.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=akpm@osdl.org \
    --cc=containers@lists.osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=serue@us.ibm.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 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®