linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Andrew Morton <akpm@linuxfoundation.org>,
	Andrew Vagin <avagin@virtuozzo.com>,
	Pavel Emelyanov <xemul@virtuozzo.com>,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	Kirill Kolyshkin <kir@openvz.org>,
	Andrey Vagin <avagin@openvz.org>
Subject: Re: [RFC 1/2] fs,eventpoll: Add ability to install target file by its number
Date: Fri, 17 Feb 2017 21:01:18 +0300	[thread overview]
Message-ID: <20170217180118.GB23766@uranus> (raw)
In-Reply-To: <CALCETrUmUOXL=72SA-pqNhQda0ic946UNnWUe_vwSHVruiyFfg@mail.gmail.com>

On Fri, Feb 17, 2017 at 09:20:34AM -0800, Andy Lutomirski wrote:
> >>
> >> This is a scary thing to let an unprivileged process do.
> >>
> >> I'm wondering if there might be a nicer way to address this using a
> >> better interface in /proc.
> >
> > Well, I tend to agree. Need to add security checking if the target
> > file is accessable by a caller. As to better interface to procfs
> > nothing comes to mind immediately. Another potential problem is that
> > since it is never guaranteed that target file number listed in fdinfo
> > matching existing /proc/pid/fd/N, so that I think we will have to
> > use this dup functionality for every target file, which of course
> > not that fast. Probably need to think more if I manage to invent
> > some better and faster interface to find where exactly target file
> > belong in the whole process tree of a container.
> 
> i was imagining some proc or proc-like interface that lets you inspect
> an open file without needing to know what process has the fd.

We will have to find out which process opened the target fd (currently
in criu we simply assume that target file is always in process which
created epoll and other scenarios are not supported. in most situations
that's enough but unfortunately we find a testcase where it's not
true and have to find a way to support migrated targets too).

> What if you introduced a new type of fd that's an "fd reference".  You
> could add a kcmp mode that tells you whether an fd reference refers to
> the same thing as a real fd, but you'd arrange for fd references to be
> otherwise useless.
> 
> Alternatively, you could simply have an interface like kcmp (maybe a
> new kcmp mode) that lets you compare an epoll set entry to an actual
> fd.  Then you could figure out what it is but only if you already have
> the fd by some other means.  Of course, if there are no references
> left, you still have a problem.  Hmm.

kcmp over target set seems to be preferred since it gonna be a way
faster. But I think about fd-ref idea too. Thanks a huge!

  reply	other threads:[~2017-02-17 18:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-17  8:30 [RFC 1/2] fs,eventpoll: Add ability to install target file by its number Cyrill Gorcunov
2017-02-17 16:52 ` Andy Lutomirski
2017-02-17 17:11   ` Cyrill Gorcunov
2017-02-17 17:20     ` Andy Lutomirski
2017-02-17 18:01       ` Cyrill Gorcunov [this message]
2017-02-17 18:34         ` Jason Baron
2017-02-17 19:45           ` Cyrill Gorcunov

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=20170217180118.GB23766@uranus \
    --to=gorcunov@gmail.com \
    --cc=akpm@linuxfoundation.org \
    --cc=avagin@openvz.org \
    --cc=avagin@virtuozzo.com \
    --cc=kir@openvz.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mtk.manpages@gmail.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=xemul@virtuozzo.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).