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]

Message-ID: <CAHc6FU4ytU5eo4bmJcL6MW+qJZAtYTX0=wTZnv4myhDBv-qZHQ@mail.gmail.com>
Date:   Fri, 3 Sep 2021 08:31:03 +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 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.

Thanks,
Andreas