linux-kernel - Re: [PATCH 3/1] xfstests: generic/062: Do not run on newer kernels

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 3 Sep 2021 11:43:08 -0400
From:   Vivek Goyal <vgoyal@...hat.com>
To:     Bruce Fields <bfields@...hat.com>
Cc:     Andreas Gruenbacher <agruenba@...hat.com>,
        fstests <fstests@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>, virtio-fs@...hat.com,
        Daniel Walsh <dwalsh@...hat.com>,
        David Gilbert <dgilbert@...hat.com>,
        Christian Brauner <christian.brauner@...ntu.com>,
        Casey Schaufler <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>,
        Giuseppe Scrivano <gscrivan@...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 03, 2021 at 10:42:34AM -0400, Bruce Fields wrote:
> Well, we could also look at supporting trusted.* xattrs over NFS.  I
> don't know much about them, but it looks like it wouldn't be a lot of
> work to specify, especially now that we've already got user xattrs?
> We'd just write a new internet draft that refers to the existing
> user.* xattr draft for most of the details.

Will be nice if we can support trusted.* xattrs on NFS.

Vivek

> 
> --b.
> 
> On Fri, Sep 3, 2021 at 2:56 AM Andreas Gruenbacher <agruenba@...hat.com> wrote:
> >
> > 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
> >
>