[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug #58941] wishlist: Support for -xattr -xattrname

From: Tavian Barnes
Subject: Re: [bug #58941] wishlist: Support for -xattr -xattrname
Date: Mon, 17 Aug 2020 09:05:17 -0400

On Sun, 16 Aug 2020 at 18:49, Morgan Weetman <mweetman@redhat.com> wrote:
> Thanks Berny .. I guess my concern is that on systems that enable an LSM
> such as SELinux, the value of having `-xattr` with no argument is zero, as
> the result will include all labelled files.

I'm not overly familiar with SELinux, but is "all labelled files" the
same as "all files"?  If not, the value isn't exactly zero.

> I'm not sure what the ratio is of SELinux (SMACK as well?) enabled systems
> vs those that aren't... but Wikipedia suggests Fedora, Debian, Ubuntu, SuSE
> and RHEL variants all carry support.

Debian and Ubuntu both support SELinux but it's not enabled by
default.  I think SELinux is likely to be a minority of Linux users,
unless you count Android :)

> [snip]
> On Fri, 14 Aug 2020 at 18:24, Bernhard Voelker <mail@bernhard-voelker.de>
> wrote:
> > Hi Morgan,
> >
> > On 2020-08-14 07:57, Morgan Weetman wrote:
> > > On a side note.. an issue has been raised against my repo regarding
> > > compatibility with BSD-based find in MacOS and Solaris, apparently -xattr
> > > in those distributions doesn't take an argument.
> > >
> > > Could you tell me what the strategy is for handling compatibility between
> > > GNU find and BSD find? Do we try to be compatible? Do we not care and
> > just
> > > do our own thing?
> >
> > as it's outside of the POSIX specification, we could do whatever we want,
> > but if there is existing behavior in other implementation, then we should
> > try to do the same.  If it turns out a feature is so much better, then we
> > can have an extra primitive.

I'm strongly in favour of this policy.  I maintain a find
implementation[1] that supports the union of features from many other
find implementations, including GNU, BSD, and macOS.  So far this has
been easy because there haven't been any conflicting features between
these implementations.  If GNU find were to implement -xattr
differently than macOS/Solaris do, it would suddenly be impossible for
me to continue to be a drop-in replacement for all these finds.

[1]: https://tavianator.com/projects/bfs.html

> > I didn't look yet what the others are doing, so just speaking out into
> > the blue, e.g.:
> > * '-xattr' (without argument) to test if a file has extended attributes,
> > * '-xattrname PATTERN' to check with a file has extended attributes
> > matching
> >   the given PATTERN, and
> > * '-xattrvalue PATTERN' to check if a file has an extended attribute
> >   with a value matching the given pattern.

macOS provides -xattrname, but it's an exact match, not a pattern.

Maybe -xattrvalue should be -xattrvalue NAME VALUE to allow you to
match specific xattrs.

Tavian Barnes

reply via email to

[Prev in Thread] Current Thread [Next in Thread]