From nobody Sun Mar 09 13:17:30 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 4Z9gYh70X7z5qHsZ; Sun, 09 Mar 2025 13:17:44 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 4Z9gYh3yg2z3TLL; Sun, 09 Mar 2025 13:17:44 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-5e673822f76so627418a12.2; Sun, 09 Mar 2025 06:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741526263; x=1742131063; 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=W1ioT5nWr4eFfA5ejBiuzPPMROAe8DZuLtxPzfAOqfA=; b=MeQpWBK+a+8wsZJuwyOCuw0gxUu/vaQq197F5oa/LT6wusVtDXKQri6i5f5ZJLiadj gp/ycVm52O6ZjLzANkc2ayl/52iWzoINr5Ol6i9SZ9gFDI8Nazk89T2xWTK9ctV+LkfY Tl0cKp+JQqYdVgnQWm+hGeoqOLsIqBHmTOd4iw4nDPDgHfKcmopUlGXjVJCKBKS6S6/4 CAh25RL4j9OaDJ0dR0TnTbjDhIiQV4VYosnvDD0lrJP1CcCvNnN6FQRP9Kv8t6TMrpnA NjPDcNRkHwp3ahrqSDPTzxqwo+fihREHBkIrshcTebhU/fpGcQDXACZoRibXkG0Zeqwz YObg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741526263; x=1742131063; 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=W1ioT5nWr4eFfA5ejBiuzPPMROAe8DZuLtxPzfAOqfA=; b=CBovxuP64R294Qvhybe3zuQRb28Nu9iN6JvdngDo0zYNILNetPg1C6n18iqJKlxMqT uQqTWkUi6mWxkzWEhrrrB/6zt6eN+dQZSEtHZMA/hKFJvsiX3ve0aacQCrBxApEb150l KWYS9lFx/uy4+Rn0EV+Ejl1K4loxH2ApJjaUVXFCzJNdzj3Y8wl7YQTeF8GKl4Bajf68 FIVFTYlV6FpPnoTXtmQT3Qp/EzTgHQ9AAF7eOwE8A/Gvx4Z+s6VdSrgQPRjdAEqEAaWS h++S3ZQ8aik9DrManUI6mxg5unkYbY0kDN4YodFu5szOlKv5PH0Iorniqo4yY6JJYAsR 6ItA== X-Forwarded-Encrypted: i=1; AJvYcCUYK9sGetsB1dOaiL3cirEL9ar0VKVp/2mN94xXXi76Fzx1LaYcOWgPF3Apl0qQNXRDyHM4LhBNCMEtFZsYJPw=@freebsd.org X-Gm-Message-State: AOJu0Yxhjq943b9HA3LqDnRmXUS451Pw23dEHiD9SYKChyLd8As0NMW1 lUkdEan91IFTgbiaRtMwixnfyxKGycmw/eJ3SNNt42aLBLi5hDtP7SFVPa6S2MiRmED5SM4yXHh nycv1HLKZvzYsea0+KHfO+xb1JcAVDhY= X-Gm-Gg: ASbGncvuQ86A8ekineFCvkS3egQDkwGWApN5kexLrr+9VH8nih1JnHjaVZ7a9U+tem+ VWgM0q2B5V3idnbNOS1Z/LL/sQzLHX4mNAhgN4WfdjUyOk2DHTRpkcsL3VgSh0PwlWeHRaC3KuR h8GV/N/DEAB7Nfi2lmtb6Kd21D0dd8u4SCGJPnVFOHelmQ3P9RX4g1lGoMn/A= X-Google-Smtp-Source: AGHT+IG/KhpUWjzGVOZeSt26IswwpRWes5aqzO8EuFru0l+d1UuZgPP5D4PSUqttcx77jRB4aDBBtIyd36C6l7kmriA= X-Received: by 2002:a05:6402:5c8:b0:5e5:bde4:755f with SMTP id 4fb4d7f45d1cf-5e5e22df03amr11733947a12.14.1741526262176; Sun, 09 Mar 2025 06:17:42 -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: In-Reply-To: From: Rick Macklem Date: Sun, 9 Mar 2025 06:17:30 -0700 X-Gm-Features: AQ5f1JqhCSiLwuwtArtWhvngCuwGcFLzIix2K9TdWbLL8vAtk6-79cBU451EuNk Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Konstantin Belousov Cc: freebsd-arch@freebsd.org, FreeBSD CURRENT , Cedric Blancher , Lionel Cons 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)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4Z9gYh3yg2z3TLL X-Spamd-Bar: ---- On Sun, Mar 9, 2025 at 1:34=E2=80=AFAM Konstantin Belousov wrote: > > CAUTION: This email originated from outside of the University of Guelph. = Do not click links or open attachments unless you recognize the sender and = know the content is safe. If in doubt, forward suspicious emails to IThelp@= uoguelph.ca. > > > On Sat, Mar 08, 2025 at 03:02:14PM -0800, 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. > > 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. > > > > 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.) > > > > At this point I have a couple of rough patches: > > https://people.freebsd.org/~rmacklem/xattr.patch - the VFS/ZFS part > > https://people.freebsd.org/~rmacklem/nfs-xattr.patch - the NFSv4 part > > > > I have a simple test program to test the above: > > https://people.freebsd.org/~rmacklem/xattrtest.c > > > > The VFS/ZFS patch defines: > > O_NAMEDATTR - similar to O_XATTR, but uses the NFSv4 named > > attribute terminology to avoid confusion with the other style of > > FreeBSD extended attributes. > > (The semantics probably are not exactly the same either. I do not > > have a Solaris system to test on, so I am going from the NFSv4 > > and Solaris doc. I have handy.) > > --> You can look at xattrtest.c to see how this is used. > > > > I have not done any userland patches and am not sure what might be > > needed? (I suspect a variant of pax/tar that knows about these is the > > minimum?) > > > > I defined a couple of new v_irflag bits to indicate that a vnode is > > a named attribute directory or a named attribute. That way, they > > are still of v_type VDIR or VREG and can be handled by most > > of the code without change. > > > > So, now for the questions... > > 1 - Do you think this should be put in FreeBSD? > > (If the consensus is no, I will try and maintain out of tree patch= es.) > > 2 - If the answer for #1 is yes, what do you think is needed beyond > > what I already have (which is a way to open the named attribute > > directory and named attributes within that directory). > How to remove the attribute? Is there a way to rename? unlinkat(2) and renameat(2). If you look at the version of https://people.freebsd.org/~rmacklem/xattrtest.c you'll see them tested. What I still working on is restrictions for other syscalls, which shouldn't work on them. (I currently don't think mkdir/rmdir/mknod/symlink should work.) I also need to look at how/what checking ZFS does w.r.t. their access permissions. (I currently think access is defined by the parent file object?) > > Could you please (try) to explain the semantic, for instance, to add the > same support for UFS? Might be tmpfs would be much easier as the target, > if some non-trivial on-disk structures needs to be added to UFS, esp. due > to SU. Not sure there is any point in doing other file systems. Anyone who wants these can use ZFS. (After all, only UFS and ZFS support NFSv4 style ACLs, so we already have features that only some file systems support.) As far as semantics, the attributes are basically a directory with regular files in it, but referred to by the parent file object instead of a name in= the file system's name space. (ZFS does generate "." and ".." in the directory, but I haven't yet looked to see what those refer to?) rick > >