LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Christian Brauner <christian@brauner.io>
To: Jan Kara <jack@suse.cz>
Cc: Amir Goldstein <amir73il@gmail.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Matthew Bobrowski <mbobrowski@mbobrowski.org>
Subject: Re: [PATCH] fanotify: remove redundant capable(CAP_SYS_ADMIN)s
Date: Thu, 23 May 2019 16:43:43 +0200	[thread overview]
Message-ID: <20190523144342.5ty2v3zxaezkq4vf@brauner.io> (raw)
In-Reply-To: <20190523144050.GE2949@quack2.suse.cz>

On Thu, May 23, 2019 at 04:40:50PM +0200, Jan Kara wrote:
> On Thu 23-05-19 15:35:18, Christian Brauner wrote:
> > So let's say the user tells me:
> > - When the "/A/B/C/target" file appears on the host filesystem,
> >   please give me access to "target" in the container at a path I tell
> >   you.
> > What I do right now is listen for the creation of the "target" file.
> > But at the time the user gives me instructions to listen for
> > "/A/B/C/target" only /A might exist and so I currently add a watch on A/
> > and then wait for the creation of B/, then wait for the creation of C/
> > and finally for the creation of "target" (Of course, I also need to
> > handle B/ and C/ being removed again an recreated and so on.). It would
> > be helpful, if I could specify, give me notifications, recursively for
> > e.g. A/ without me having to place extra watches on B/ and C/ when they
> > appear. Maybe that's out of scope...
> 
> I see. But this is going to be painful whatever you do. Consider for
> example situation like:
> 
> mkdir -p BAR/B/C/
> touch BAR/B/C/target
> mv BAR A
> 
> Or even situation where several renames race so that the end result creates
> the name (or does not create it depending on how renames race). And by the
> time you decide A/B/C/target exists, it doesn't need to exist anymore.
> Honestly I don't see how you want to implement *any* solution in a sane
> way. About the most reliable+simple would seem to be stat "A/B/C/target"
> once per second as dumb as it is.

What we have kinda works rn good enough. And yes, it's inherently racy.
Basically, iirc we only watch that it exists once, then create the thing
for the container and then consider our job done. If that thing is
removed under us we don't really care.

Christian

  reply	other threads:[~2019-05-23 14:43 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-22 16:31 Christian Brauner
2019-05-22 18:29 ` Amir Goldstein
2019-05-22 18:57   ` Christian Brauner
2019-05-22 20:00     ` Amir Goldstein
2019-05-23  9:55       ` Christian Brauner
2019-05-23 10:25         ` Amir Goldstein
2019-05-23 10:42           ` Christian Brauner
2019-05-23 11:40             ` Amir Goldstein
2019-05-23 11:58               ` Christian Brauner
2019-05-23 13:16                 ` Amir Goldstein
2019-05-23 13:35                   ` Christian Brauner
2019-05-23 14:40                     ` Jan Kara
2019-05-23 14:43                       ` Christian Brauner [this message]
2019-05-23 15:15                       ` Amir Goldstein
2019-06-05 10:26           ` Matthew Bobrowski

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=20190523144342.5ty2v3zxaezkq4vf@brauner.io \
    --to=christian@brauner.io \
    --cc=amir73il@gmail.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbobrowski@mbobrowski.org \
    --subject='Re: [PATCH] fanotify: remove redundant capable(CAP_SYS_ADMIN)s' \
    /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

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).