On Sat, Mar 29, 2025 at 07:35:03AM -0700, Rick Macklem wrote: > On Fri, Mar 28, 2025 at 1:31 PM Dennis Clarke <dcla...@blastwave.org> wrote: > > > > On 3/8/25 18:02, Rick Macklem wrote: > > > First off, I cross posted because I don't think many read freebsd-arch@. > > > There seems to be a nice market for Solaris style extended attributes. > > > > Hold on a moment. > > > > I have been following this discussion now for a while and I am trying to > > figure who wants this? Why? Is this a "make work" project wherein a pile > > of code and testing will needed? Where the word "pile" may mean years. > > > > > Since ZFS is already wired for them, adding the basics is pretty > > > straightforward. I am not suggesting that they should replace the > > > current FreeBSD extended attributes. > > > > > > > Well if you decide to go into NFS with xattr then you may as well dig > > into UFS with xattr also. Perhaps that would be insane however once you > > deal with ACL handling in tools like tar and ls then you will need to > > ponder UFS also. That means output similar to Solaris /usr/xpg4/bin/ls > > like so : > > > > The following example shows how to display compact ACL > > information on a ZFS directory. > > > > % ls -dV test.dir > > drwxr-xr-x 2 marks staff 2 Mar 14 10:17 test.dir > > owner@:--------------:------:deny > > owner@:rwxp---A-W-Co-:------:allow > > group@:-w-p----------:------:deny > > group@:r-x-----------:------:allow > > everyone@:-w-p---A-W-Co-:------:deny > > everyone@:r-x---a-R-c--s:------:allow > > > > The following example illustrates the ls -v behavior when > > listing ACL information on a UFS file. > > > > $ ls -v file.3 > > -rw-r--r-- 1 root root 2703 Mar 14 10:59 file.3 > > 0:user::rw- > > 1:group::r-- #effective:r-- > > 2:mask:r-- > > 3:other:r-- > > > > I see considerable differences between the FreeBSD base ls and Solaris > > ls which does handle ACL data in both UFS and ZFS. Does this need to > > be dragged onto the table along with every other file handling tool > > and system call? I see a tarpit ( no pun intended ) this opens up. > Well, the NFSv4 ACLs exist now in FreeBSD for ZFS and no one has been pushing > for "ls" to know how to display them. (See getfacl(1)) > > ZFS also already supports extended attributes and, as above, "ls" does not > know how to display them. (See lsextattr(1), getextattr(1)...) > > I do not see why commands like "ls" need to know about these things. > tar/pax is a different story, since archival of them seems necessary. > > All the patches I have created does is add a different, Solaris like > syscall/KABI > for manipulating extended attributes. The patches just use code that > is already in ZFS to > handle the extended attributes as files in a directory. > ZFS currently appears to store extended attributes two ways: > "zfs set xattr=sa <file system>" - For this one, small extended > attributes are stored > in some sort of storage block. If the extended attribute is too > large for the storage > block, it spills over into a file in a directory. > --> The alternate syscall/KAPI does not work and is disabled for > this property setting. > > "zfs set xattr=on <file system>" - Also called "dir", all extended > attributes are stored > as regular files, with a directory holding their names. > --> The alternate syscall/KAPI the patches adds provides a more > direct way to access > this directory and the files that store the extended attributes. > The main advantage of this syscall/KAPI is that large extended > attributes are supported. > > Since this is already how ZFS stores extended attributes, I assume > send/recv knows > how to deal with them. tar/pax will need to know the alternate > syscall/KAPI to handle > large extended attributes if this syscall/KABI is used. (The thread I > mentioned over > on freebsd-hackers@ mentions a patched version of pax/tar, but I have > not looked at it.) > > Do many people need/want to handle large extended attributes? > I'd guess not, but I really have no idea what FreeBSD users use? > (I only hear about problems w.r.t. NFS, so I have no idea how many use > it without > problems.) > For NFSv4, this alternate model is supported as "named attributes". There is > as > extension to NFSv4.2 for the Linux/FreeBSD model for small extended > attributes, > but this extension doesn't work for clients on Windows, Mac OSX or Solaris. > As such, there is another niche market for some NFSv4 clients. > > The patches are rough, but basically done. I am now in testing mode. It was > not > exactly a "make work" project. More a "I was curious to see how easily > the Solaris > style syscall/kapi could be implemented" project. > > I do not see any reason why UFS would need/want this alternate syscall/kapi, > since anyone wanting/needing large extended attributes could use ZFS, which > is what most managed storage will use anyhow. > > In summary, other than the patches I've already done, a patched version of > tar/pax is about all I think is needed. >
I had added filesystem extended attribute support to libarchive, which is what FreeBSD's tar(1) is based off of. I upstreamed that, so that's taken care of. FreeBSD's tar(1) has supported extended attributes since 2020 (see libarchive PR 1409: https://github.com/libarchive/libarchive/pull/1409) > > > For those not familiar with them (I am not very familiar myself;-), > > > a Solaris style extended attribute is in a directory that hangs off > > > the file object and the entries in the directory (the attributes) can > > > be manipulated with open/read/write/lseek just like a regular file. > > > (They can be as large as a regular file, but there is no atomicity > > > guarantees.) > > > > I just, today, shutdown my last Solaris server which was a Fujitsu > > SPARC64 machine and it was draining power and making heat for a number > > of years in my life. Certainly it was using ZFS but not the ZFS that we > > can use or "zfs send" anywhere. The botched up stuff that is totally not > > compatible with OpenZFS of any flavour. This means that I had to do a > > blunt force medieval tarball backup. Nothing else would ever be usable > > for recovery. > > > > Never in the many many years of using Solaris with ZFS have I felt the > > need to drag in xattr's on people. Not once in two decades. Pretty sure > > I did some very early testing within the OpenSolaris project and can not > > recall the desperate need thereafter. > > > > So who wants this? Why? Is there some atom-splitting world changing > > reason that the extended attributes are needed in FreeBSD? Just one data point here: HardenedBSD uses filesystem extended attributes to toggle certain exploit mitigations on a per-application basis. That's why we added support to libarchive: so we can ship certain packages with exploit mitigations pre-toggled. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
signature.asc
Description: PGP signature
