[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHc6FU5quZWQtZ3fRfM_ZseUsweEbJA0aAkZvQEF5u9MJhrqdQ@mail.gmail.com>
Date: Fri, 3 Sep 2021 08:56:08 +0200
From: Andreas Gruenbacher <agruenba@...hat.com>
To: Vivek Goyal <vgoyal@...hat.com>
Cc: fstests <fstests@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>, virtio-fs@...hat.com,
dwalsh@...hat.com, dgilbert@...hat.com,
christian.brauner@...ntu.com, casey.schaufler@...el.com,
LSM <linux-security-module@...r.kernel.org>,
selinux@...r.kernel.org, "Theodore Ts'o" <tytso@....edu>,
Miklos Szeredi <miklos@...redi.hu>, gscrivan@...hat.com,
"Fields, Bruce" <bfields@...hat.com>,
stephen.smalley.work@...il.com, Dave Chinner <david@...morbit.com>,
Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH 3/1] xfstests: generic/062: Do not run on newer kernels
On Fri, Sep 3, 2021 at 8:31 AM Andreas Gruenbacher <agruenba@...hat.com> wrote:
> On Thu, Sep 2, 2021 at 5:47 PM Vivek Goyal <vgoyal@...hat.com> wrote:
> > xfstests: generic/062: Do not run on newer kernels
> >
> > This test has been written with assumption that setting user.* xattrs will
> > fail on symlink and special files. When newer kernels support setting
> > user.* xattrs on symlink and special files, this test starts failing.
>
> It's actually a good thing that this test case triggers for the kernel
> change you're proposing; that change should never be merged. The
> user.* namespace is meant for data with the same access permissions as
> the file data, and it has been for many years. We may have
> applications that assume the existing behavior. In addition, this
> change would create backwards compatibility problems for things like
> backups.
>
> I'm not convinced that what you're actually proposing (mapping
> security.selinux to a different attribute name) actually makes sense,
> but that's a question for the selinux folks to decide. Mapping it to a
> user.* attribute is definitely wrong though. The modified behavior
> would affect anybody, not only users of selinux and/or virtiofs. If
> mapping attribute names is actually the right approach, then you need
> to look at trusted.* xattrs, which exist specifically for this kind of
> purpose. You've noted that trusted.* xattrs aren't supported over nfs.
> That's unfortunate, but not an acceptable excuse for messing up user.*
> xattrs.
Another possibility would be to make selinux use a different
security.* attribute for this nested selinux case. That way, the
"host" selinux would retain some control over the labels the "guest"
uses.
Thanks,
Andreas
Powered by blists - more mailing lists