archive mirror
 help / color / mirror / Atom feed
From: Ondrej Mosnacek <>
To: Al Viro <>
Cc: SElinux list <>,
	Paul Moore <>,
Subject: Re: [PATCH v2 0/4] selinux: fix race when removing selinuxfs entries
Date: Tue, 3 Sep 2019 12:56:57 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Aug 8, 2019 at 9:59 AM Ondrej Mosnacek <> wrote:
> On Thu, Aug 1, 2019 at 6:09 PM Al Viro <> wrote:
> > On Thu, Aug 01, 2019 at 04:02:39PM +0200, Ondrej Mosnacek wrote:
> > > After hours and hours of getting familiar with dcache and debugging,
> > > I think I finally found a solution that works and hopefully stands a
> > > chance of being committed.
> > >
> > > The series still doesn't address the lack of atomicity of the policy
> > > reload transition, but this is part of a wider problem and can be
> > > resolved later. Let's fix at least the userspace-triggered lockup
> > > first.
> >
> > I don't think this is the right approach.  Consider the related problem:
> > what happens if somebody has mounted something upon a selinuxfs file?
> > That is the hard part here, and AFAICS your variant doesn't help it
> > at all...
> But that's another independent problem and it's not even fixed in
> debugfs, which for now I'm treating as the baseline as I don't know of
> any other filesystem that needs to remove its own directory trees in a
> similar way.
> I get that you don't want me to add a new function to the dcache API
> that isn't bulletproof (and what I wrote here is apparently still far
> from it), but you also previously said that I shouldn't open-code this
> stuff in selinuxfs.c... I don't think I have the wits to write a
> common function that handles all the possible issues, but I still want
> to fix at least this one scenario (dcache_readdir() vs.
> sel_remove_entries()).
> Is there some way I could do this without getting a NACK from you? For
> example, I thought of taking what is now debugfs_remove[_recursive]()
> out of debugfs into, say, fs/libfs.c (providing some optional callback
> to allow debugfs to do its __debugfs_file_removed() business) and use
> this function(s) from both debugfs and selinuxfs. This way we could
> later fix the leftover mount issue in one place and both filesystems
> would (hopefully) immediately benefit from it. Would that be a
> feasible way forward?


Ondrej Mosnacek <omosnace at redhat dot com>
Software Engineer, Security Technologies
Red Hat, Inc.

      reply	other threads:[~2019-09-03 10:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-01 14:02 [PATCH v2 0/4] selinux: fix race when removing selinuxfs entries Ondrej Mosnacek
2019-08-01 14:02 ` [PATCH v2 1/4] d_walk: optionally lock also parent inode Ondrej Mosnacek
2019-08-01 16:10   ` Al Viro
2019-08-01 16:12   ` Al Viro
2019-08-01 14:02 ` [PATCH v2 2/4] d_walk: add leave callback Ondrej Mosnacek
2019-08-01 14:02 ` [PATCH v2 3/4] dcache: introduce d_genocide_safe() Ondrej Mosnacek
2019-08-01 14:02 ` [PATCH v2 4/4] selinux: use d_genocide_safe() in selinuxfs Ondrej Mosnacek
2019-08-01 16:09 ` [PATCH v2 0/4] selinux: fix race when removing selinuxfs entries Al Viro
2019-08-08  7:59   ` Ondrej Mosnacek
2019-09-03 10:56     ` Ondrej Mosnacek [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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

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