From: Eric Paris <eparis@redhat.com>
To: Paul Moore <paul@paul-moore.com>
Cc: Josh Boyer <jwboyer@fedoraproject.org>,
James Morris <jmorris@namei.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-security-module <linux-security-module@vger.kernel.org>,
"Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>
Subject: Re: [GIT] SELinux fixes
Date: Fri, 13 Dec 2013 09:52:14 -0500 [thread overview]
Message-ID: <1386946334.2919.5.camel@localhost> (raw)
In-Reply-To: <CAHC9VhRHeukZ0e_RYDFuh_eQThZnNtNnsUgtB5S+VjHjAXcCKQ@mail.gmail.com>
On Fri, 2013-12-13 at 09:36 -0500, Paul Moore wrote:
> On Fri, Dec 13, 2013 at 9:02 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> > Should probably figure out which path to take on this one soon:
> >
> > http://thread.gmane.org/gmane.linux.kernel/1611662
> >
> > A revert might be the easiest for now.
>
> Yeah, I followed the discussion you and Eric were having earlier this
> week; I was hoping that you guys would be able to arrive at a fix as I
> would much prefer to fix the issue and not have to revert.
>
> If I don't see something from Eric within the next couple of hours
> I'll go ahead and do the revert.
Paul, please revert 102aefdda4d8275ce7d7100bc16c88c74272b260
SELinux policy can specify if it should use a filesystem's xattrs or
not. In current policy we have a specification that fuse should not use
xattrs but fuse.glusterfs should use xattrs. This patch has a bug in
which non-glusterfs filesystems would match the rule saying
fuse.glusterfs should use xattrs. If both fuse and the particular
filesystem in question are not written to handle xattr calls during the
mount command, they will deadlock.
I have fixed the bug to do proper matching, however I believe a revert
is still the correct solution. The reason I believe that is because the
code still does not work. The s_subtype is not set until after the
SELinux hook which attempts to match on the ".gluster" portion of the
rule. So we cannot match on the rule in question. The code is useless.
In the next cycle the code should be re-re-verted and fixed, but we also
need to address the fact that it just plain doesn't work.
-Eric
next prev parent reply other threads:[~2013-12-13 14:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-13 2:52 James Morris
2013-12-13 14:02 ` Josh Boyer
2013-12-13 14:36 ` Paul Moore
2013-12-13 14:52 ` Eric Paris [this message]
2013-12-13 14:56 ` Paul Moore
2013-12-23 23:55 James Morris
2014-02-10 0:48 James Morris
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=1386946334.2919.5.camel@localhost \
--to=eparis@redhat.com \
--cc=jmorris@namei.org \
--cc=jwboyer@fedoraproject.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=torvalds@linux-foundation.org \
/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
all inboxes | Powered by JetHome®