From nobody Sat Mar 29 19:39:02 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZQ74g72KFz5ry7j for ; Sat, 29 Mar 2025 19:39:15 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZQ74g4p9Vz49Z6 for ; Sat, 29 Mar 2025 19:39:15 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-5e6ff035e9aso1684997a12.0 for ; Sat, 29 Mar 2025 12:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743277153; x=1743881953; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=uGdIWI7xzm8gNmw8WOwoNTdxbea+HsYhbyYsFLrSXDs=; b=SSQczQKBC7+fQXjphx/w91+Q/BWep/lEAQwqC0n6hreSdd6TuE73e5+w6UOqLiw4Nn qrk/DdwvOiRHY/917KQbdMLZLnFixLfmB9+Vyytb/s5jpJT4Ol3kJHo1+5D/EtrMKE1N BHe4FK4ufH13JuGaZhoKql7kl2qKnR5TZM6YiDoO3rpS+rvH7PKuZC8HHLHKMw5TGTUs 2dCvQ4/mb2XR6sxecdNTe/TuP/Nzop2Rv+K8eWJe348iRac/rZnNzTM6/YGxJjKR0R/w 9jlZvwh7UyCDCiQLlQBLJILoDEqk1nDmN/pW5RzmdiyFOwfy1Da/QADKTvhLSSEVn677 MTag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743277153; x=1743881953; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=uGdIWI7xzm8gNmw8WOwoNTdxbea+HsYhbyYsFLrSXDs=; b=iMUl7xXqYDz3w8aBn1RnoYIvgellitZCNk3XUpqSp+hwvXN5Sa8yHU9vOw2MuKQ7Mp 3TBvGye3AijdXxBypvTKU04fmDAB7+IKuHhQ7IZoCeRya4Hf9v8IN+JlKtMftH+cXdNK h2rPiKrCKw9JcCdN1Ld8fFiiTymNlatZpy+riN8bzwPVHKMQj+knzZT0+er6SJzF/xPB gYjHbOkF4Zpw8XIBpTyC+JL3zNTJx+LAwH1LJjxf0RH8LeG/EDgBv4J5v/lAkliwHLmz 8Z67HjHB/byWENqNCUzTE3QcdDWjLi4VCr8RoVLjCXMObeULxMfThQhh864WG8zsusRe mLmQ== X-Forwarded-Encrypted: i=1; AJvYcCVLXl6nNJ16WNGbwGkPNv59AWBxqNJTdQLbB6jIlQAF0Nm2oGg6vk2IeyPJZeHTrQmFfPjpu/yfApJ0Hg70XHk=@freebsd.org X-Gm-Message-State: AOJu0YwUNig20GY62mQQwK5kox4zOtd6en2TEd9YcfZBWi/IJ2sYY94Y fA/9Fv30b6w/GcsD+/NTELx5Zi72raf7hndGDdOznnFkx6lfZPoCYTeCvuxA8qlfmIaMvOEQLS/ ZUQ5PxeYpNv8bxcSJMjttdLX8FB6f X-Gm-Gg: ASbGnctoVpcjNTwAemBhCE/pa+C/FvELIxp64A1uq8xS74lQ/Qjz0YIrE1tYyLbVsW4 P5uJPsnU+G9vVjL3DGAy9IJ1o/b32g+q0+RCCBeMa+OpIlrckqfSzTgJ5jwGDnLpQrRNfRHZLyR 1mzJETtP4GLstMcDpsEyD4pMfzCccPyq94kEXboq6bcIP/84PL85qLZ/VEeqVZM93rruCg X-Google-Smtp-Source: AGHT+IGchxsqIYH27fSlMsYGFhesLRAHhTU59JlX3Yl+qEiQJwQzVHCFRq6B9MEXPsKme0owSZb0Jjx0IyxpOo3Ji3s= X-Received: by 2002:a05:6402:3604:b0:5ed:1841:18c5 with SMTP id 4fb4d7f45d1cf-5edfdd21ad3mr3241906a12.30.1743277152772; Sat, 29 Mar 2025 12:39:12 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <410014e4-75a6-4923-8f84-3935cab41c31@blastwave.org> In-Reply-To: From: Rick Macklem Date: Sat, 29 Mar 2025 12:39:02 -0700 X-Gm-Features: AQ5f1JoIrkSSP2VwrutLq-5n-DecBxqAuk7WL4zSPQVh5pNH7x5MUQ4rBN-yUYk Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Shawn Webb Cc: Dennis Clarke , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4ZQ74g4p9Vz49Z6 X-Spamd-Bar: ---- On Sat, Mar 29, 2025 at 9:15=E2=80=AFAM Shawn Webb wrote: > > On Sat, Mar 29, 2025 at 07:35:03AM -0700, Rick Macklem wrote: > > On Fri, Mar 28, 2025 at 1:31=E2=80=AFPM Dennis Clarke wrote: > > > > > > On 3/8/25 18:02, Rick Macklem wrote: > > > > First off, I cross posted because I don't think many read freebsd-a= rch@. > > > > There seems to be a nice market for Solaris style extended attribut= es. > > > > > > 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 p= ile > > > 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 y= ou > > > 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/l= s > > > 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 Solari= s > > > 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 p= ushing > > 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=3Dsa " - 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=3Don " - 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". The= re is as > > extension to NFSv4.2 for the Linux/FreeBSD model for small extended att= ributes, > > but this extension doesn't work for clients on Windows, Mac OSX or Sola= ris. > > 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, w= hich > > 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) Ok, thanks for the info. If this stuff goes into FreeBSD, it probably needs to be tweaked to use the different syscall API so that it can handle large attributes and maybe the attribute's mode. (someday, maybe?) rick > > > > > 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) c= an > > > > 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 numbe= r > > > 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 usabl= e > > > for recovery. > > > > > > Never in the many many years of using Solaris with ZFS have I felt th= e > > > need to drag in xattr's on people. Not once in two decades. Pretty su= re > > > 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. Just curious. Does it use "system" or "user" attribute space? rick > > 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/0= 3A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc