All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Seth Forshee <seth.forshee@canonical.com>,
	Jiri Slaby <jslaby@suse.cz>,
	Serge Hallyn <serge.hallyn@canonical.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] tty: Allow stealing of controlling ttys within user namespaces
Date: Fri, 7 Feb 2014 08:40:13 -0800	[thread overview]
Message-ID: <20140207164013.GA17653@kroah.com> (raw)
In-Reply-To: <8738kdq7ng.fsf@xmission.com>

On Fri, Jan 24, 2014 at 03:31:15PM -0800, Eric W. Biederman wrote:
> Seth Forshee <seth.forshee@canonical.com> writes:
> 
> > root is allowed to steal ttys from other sessions, but it
> > requires system-wide CAP_SYS_ADMIN and therefore is not possible
> > for root within a user namespace. This should be allowed so long
> > as the process doing the stealing is privileged towards the
> > session which currently owns the tty.
> >
> > Update this code to only require CAP_SYS_ADMIN in the user
> > namespaces of the target session's tasks, allowing the tty to be
> > stolen from sessions whose tasks are in the same or lesser
> > privileged user namespaces.
> 
> This code looks essentially correct.  I would like to look at it a bit
> more before we merge it, just to ensure something silly hasn't been
> missed, but the only thing that concerns me at this point is are we
> checking the proper per task bits.
> 
> The case I am currently worrying about is a task that does something
> privileged drops perms sets dumpable and then calls setns() on the
> userns.
> 
> So I think we may have to solve the dumpable problem at the same time as
> we solve this issue.
> 
> Now I don't know if it makes sense to take this through the tty tree or
> my userns tree.  I am inclined to take it through the userns tree simply
> because I am reviewing it and I have seen the several failed attempts at
> this but if Greg wants it in the tty tree I won't object.

No objection from me.

thanks,

greg k-h

      reply	other threads:[~2014-02-07 16:39 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-22 14:53 [PATCH v2] tty: Allow stealing of controlling ttys within user namespaces Seth Forshee
2014-01-24 23:31 ` Eric W. Biederman
2014-02-07 16:40   ` Greg Kroah-Hartman [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=20140207164013.GA17653@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=ebiederm@xmission.com \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=serge.hallyn@canonical.com \
    --cc=seth.forshee@canonical.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.