linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ian Kent <raven@themaw.net>
To: Oleg Nesterov <oleg@redhat.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	Stanislav Kinsbursky <skinsbursky@parallels.com>,
	Jeff Layton <jlayton@redhat.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-nfs@vger.kernel.org, devel@openvz.org,
	bfields@fieldses.org, bharrosh@panasas.com
Subject: Re: call_usermodehelper in containers
Date: Fri, 25 Mar 2016 15:25:51 +0800	[thread overview]
Message-ID: <1458890751.19150.11.camel@themaw.net> (raw)
In-Reply-To: <20160325012857.GA17892@redhat.com>

On Fri, 2016-03-25 at 02:28 +0100, Oleg Nesterov wrote:
> Hi Ian,
> 
> I can't really recall this old discussion, so I can be easily wrong...
> 
> On 03/24, Ian Kent wrote:
> > 
> > On Mon, 2013-11-18 at 18:28 +0100, Oleg Nesterov wrote:
> > > 
> > > IOW. Please the the "patch" below. It is obviously incomplete and
> > > wrong,
> > > and it can be more clear/clean. And probably we need another API.
> > > Just
> > > to explain what I mean.
> 
> I hope you didn't miss this part ;)

Not at all.

> 
> In particular, we want to turn task_work_add(..., bool notify) into
> task_work_add(..., how_to_notify mask) and this "mask" should allow
> to force TIF_SIGPENDING.

The point of posting the reply was to try and get some advice as my
understanding of the signalling subsystem is fairly poor.

LOL, I'll have another look at the task_work_add() code and see if I can
understand what your trying to tell me.

> 
> > > With this patch call_usermodehelper(..., UMH_IN_MY_NS) should do
> > > exec
> > > from the caller's namespace.
> > 
> > Umm ... I don't think this can work.
> > 
> > I don't think it can be assumed that the init process of a container
> > will behave like an init process.
> > 
> > If you try and do this with a Docker container that has /bin/bash as
> > the
> > init process signals never arrive and work doesn't start until some
> > other signal arrives
> 
> only if it blocks/ignores SIGCHLD? But this doesn't matter, see above
> and
> note the "until we have task_work_add_interruptibel()" in the pseudo
> -code
> I showed.

It seems, and this is not the only case I've encountered, that the init
process in docker containers can be a problem when you want to capture
and handle signals.

I've seen this with /bin/bash and supervisord so far.
I don't know if it is the docker container creation doing this or
something else .... certainly I can catch signals within subordinate
processes.

The other thing that occurs to me is that just about anything in a
container could be subverted so the definition of a privileged process
which can be used as a template form execution is essentially undefined.

Mmm ... maybe I've got that wrong too, ;)

Ian

      reply	other threads:[~2016-03-25  7:26 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-11 12:18 call_usermodehelper in containers Jeff Layton
2013-11-11 12:43 ` [Devel] " Vasily Kulikov
2013-11-11 13:26   ` Jeff Layton
2013-11-12  0:47 ` Greg KH
2013-11-12 11:12   ` Jeff Layton
2013-11-12 13:02     ` Stanislav Kinsbursky
2013-11-12 13:30       ` Jeff Layton
2013-11-15  5:05         ` Eric W. Biederman
2013-11-15 10:40         ` Stanislav Kinsbursky
2013-11-15 11:03           ` Eric W. Biederman
2013-11-15 11:54             ` Stanislav Kinsbursky
2016-02-12 23:39               ` Ian Kent
2016-02-13 16:08                 ` Stanislav Kinsburskiy
2016-02-15  0:11                   ` Ian Kent
2016-02-18  3:17                     ` Eric W. Biederman
2013-11-18 17:28             ` Oleg Nesterov
2013-11-18 18:02               ` Oleg Nesterov
2013-11-19 14:51                 ` Jeff Layton
2016-02-11  0:17               ` Ian Kent
2016-02-18  2:57                 ` Eric W. Biederman
2016-02-18  3:43                   ` Kamezawa Hiroyuki
2016-02-18  6:36                     ` Ian Kent
2016-02-18  7:37                       ` Ian Kent
2016-02-18 20:45                         ` Eric W. Biederman
2016-02-19  3:08                           ` Kamezawa Hiroyuki
2016-02-19  5:37                             ` Ian Kent
2016-02-19  9:30                               ` Kamezawa Hiroyuki
2016-02-20  3:28                                 ` Ian Kent
2016-02-19  5:14                           ` Ian Kent
2016-02-23  2:55                             ` Ian Kent
2016-02-23 14:36                               ` J. Bruce Fields
2016-02-24  0:55                                 ` Ian Kent
2016-03-24  7:45               ` Ian Kent
2016-03-25  1:28                 ` Oleg Nesterov
2016-03-25  7:25                   ` Ian Kent [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=1458890751.19150.11.camel@themaw.net \
    --to=raven@themaw.net \
    --cc=bfields@fieldses.org \
    --cc=bharrosh@panasas.com \
    --cc=devel@openvz.org \
    --cc=ebiederm@xmission.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jlayton@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=skinsbursky@parallels.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;
as well as URLs for NNTP newsgroup(s).