From: Ondrej Mosnacek <firstname.lastname@example.org>
To: Al Viro <email@example.com>
Cc: SElinux list <firstname.lastname@example.org>,
Paul Moore <email@example.com>,
Subject: Re: [PATCH v2 0/4] selinux: fix race when removing selinuxfs entries
Date: Thu, 8 Aug 2019 09:59:41 +0200 [thread overview]
Message-ID: <CAFqZXNs5igF_G8=EA+bD-JRorS6xeuCiXQr5vweaJFYNwEVKZA@mail.gmail.com> (raw)
On Thu, Aug 1, 2019 at 6:09 PM Al Viro <firstname.lastname@example.org> 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
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.
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.
next prev parent reply other threads:[~2019-08-08 7:59 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 [this message]
2019-09-03 10:56 ` Ondrej Mosnacek
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).