public inbox for linux-next@vger.kernel.org 
 help / color / mirror / Atom feed
From: Stephen Rothwell <sfr@canb•auug.org.au>
To: "Eric W. Biederman" <ebiederm@xmission•com>,
	Al Viro <viro@ZenIV•linux.org.uk>
Cc: linux-next@vger•kernel.org, linux-kernel@vger•kernel.org
Subject: linux-next: manual merge of the userns tree with the vfs tree
Date: Tue, 16 Dec 2014 14:21:09 +1100	[thread overview]
Message-ID: <20141216142109.4a67e8b0@canb.auug.org.au> (raw)

[-- Attachment #1: Type: text/plain, Size: 3704 bytes --]

Hi Eric,

Today's linux-next merge of the userns tree got a conflict in
kernel/user_namespace.c between commits 3c0411846118 ("switch the rest
of proc_ns_operations to working with &...->ns") and 64964528b24e
("make proc_ns_operations work with struct ns_common * instead of void
*") from the vfs tree and commits 273d2c67c3e1 ("userns: Don't allow
setgroups until a gid mapping has been setablished") and 9cc46516ddf4
("userns: Add a knob to disable setgroups on a per user namespace
basis") from the userns tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb•auug.org.au

diff --cc kernel/user_namespace.c
index 1491ad00388f,ad419b04c146..000000000000
--- a/kernel/user_namespace.c
+++ b/kernel/user_namespace.c
@@@ -842,12 -849,101 +850,106 @@@ static bool new_idmap_permitted(const s
  	return false;
  }
  
 +static inline struct user_namespace *to_user_ns(struct ns_common *ns)
 +{
 +	return container_of(ns, struct user_namespace, ns);
 +}
 +
+ int proc_setgroups_show(struct seq_file *seq, void *v)
+ {
+ 	struct user_namespace *ns = seq->private;
+ 	unsigned long userns_flags = ACCESS_ONCE(ns->flags);
+ 
+ 	seq_printf(seq, "%s\n",
+ 		   (userns_flags & USERNS_SETGROUPS_ALLOWED) ?
+ 		   "allow" : "deny");
+ 	return 0;
+ }
+ 
+ ssize_t proc_setgroups_write(struct file *file, const char __user *buf,
+ 			     size_t count, loff_t *ppos)
+ {
+ 	struct seq_file *seq = file->private_data;
+ 	struct user_namespace *ns = seq->private;
+ 	char kbuf[8], *pos;
+ 	bool setgroups_allowed;
+ 	ssize_t ret;
+ 
+ 	/* Only allow a very narrow range of strings to be written */
+ 	ret = -EINVAL;
+ 	if ((*ppos != 0) || (count >= sizeof(kbuf)))
+ 		goto out;
+ 
+ 	/* What was written? */
+ 	ret = -EFAULT;
+ 	if (copy_from_user(kbuf, buf, count))
+ 		goto out;
+ 	kbuf[count] = '\0';
+ 	pos = kbuf;
+ 
+ 	/* What is being requested? */
+ 	ret = -EINVAL;
+ 	if (strncmp(pos, "allow", 5) == 0) {
+ 		pos += 5;
+ 		setgroups_allowed = true;
+ 	}
+ 	else if (strncmp(pos, "deny", 4) == 0) {
+ 		pos += 4;
+ 		setgroups_allowed = false;
+ 	}
+ 	else
+ 		goto out;
+ 
+ 	/* Verify there is not trailing junk on the line */
+ 	pos = skip_spaces(pos);
+ 	if (*pos != '\0')
+ 		goto out;
+ 
+ 	ret = -EPERM;
+ 	mutex_lock(&userns_state_mutex);
+ 	if (setgroups_allowed) {
+ 		/* Enabling setgroups after setgroups has been disabled
+ 		 * is not allowed.
+ 		 */
+ 		if (!(ns->flags & USERNS_SETGROUPS_ALLOWED))
+ 			goto out_unlock;
+ 	} else {
+ 		/* Permanently disabling setgroups after setgroups has
+ 		 * been enabled by writing the gid_map is not allowed.
+ 		 */
+ 		if (ns->gid_map.nr_extents != 0)
+ 			goto out_unlock;
+ 		ns->flags &= ~USERNS_SETGROUPS_ALLOWED;
+ 	}
+ 	mutex_unlock(&userns_state_mutex);
+ 
+ 	/* Report a successful write */
+ 	*ppos = count;
+ 	ret = count;
+ out:
+ 	return ret;
+ out_unlock:
+ 	mutex_unlock(&userns_state_mutex);
+ 	goto out;
+ }
+ 
+ bool userns_may_setgroups(const struct user_namespace *ns)
+ {
+ 	bool allowed;
+ 
+ 	mutex_lock(&userns_state_mutex);
+ 	/* It is not safe to use setgroups until a gid mapping in
+ 	 * the user namespace has been established.
+ 	 */
+ 	allowed = ns->gid_map.nr_extents != 0;
+ 	/* Is setgroups allowed? */
+ 	allowed = allowed && (ns->flags & USERNS_SETGROUPS_ALLOWED);
+ 	mutex_unlock(&userns_state_mutex);
+ 
+ 	return allowed;
+ }
+ 
 -static void *userns_get(struct task_struct *task)
 +static struct ns_common *userns_get(struct task_struct *task)
  {
  	struct user_namespace *user_ns;
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

             reply	other threads:[~2014-12-16  3:21 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-16  3:21 Stephen Rothwell [this message]
2014-12-16  4:40 ` linux-next: manual merge of the userns tree with the vfs tree Eric W. Biederman
  -- strict thread matches above, loose matches on Subject: below --
2018-06-20  2:39 Stephen Rothwell
2018-08-06  7:50 ` Stephen Rothwell
2018-08-06 17:35   ` Eric W. Biederman
2018-06-20  1:44 Stephen Rothwell
2018-06-20  3:31 ` Stephen Rothwell
2018-06-19  4:56 Stephen Rothwell
2018-06-19 10:11 ` Eric W. Biederman
2015-05-25  9:49 Stephen Rothwell
2014-12-10  6:27 Stephen Rothwell
2014-12-10  6:21 Stephen Rothwell
2013-11-08  6:50 Stephen Rothwell
2013-11-08  6:50 Stephen Rothwell
2013-11-08  6:49 Stephen Rothwell
2013-11-08  6:49 Stephen Rothwell

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=20141216142109.4a67e8b0@canb.auug.org.au \
    --to=sfr@canb$(echo .)auug.org.au \
    --cc=ebiederm@xmission$(echo .)com \
    --cc=linux-kernel@vger$(echo .)kernel.org \
    --cc=linux-next@vger$(echo .)kernel.org \
    --cc=viro@ZenIV$(echo .)linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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