From nobody Thu Mar 27 02:28:32 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 4ZNSJY5BQJz5rZlJ; Thu, 27 Mar 2025 02:28:45 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 4ZNSJY13Qlz3RRC; Thu, 27 Mar 2025 02:28:45 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-5e60cfef9cfso701369a12.2; Wed, 26 Mar 2025 19:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743042523; x=1743647323; 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=OGwrNVh/WZTTtw7uAqgZK0CpG9xq3xfhc8jxsCdvx0E=; b=cNi8ZtYXHCtjSLtWZo9CHykpbLBkx5pkGvfGsc58IKZafwfJPESz91cezthDQ8b9DS c8Xs7EwrLeXcMJJi1lNG9Rjcl6zCyHoR7Kp+jfV9ylKhSSRC/F9xbRATAZeK4mxlMYDP DsKjNVtmkIkmy+zZhnNmb6w4566zzicgfloqggpq3rHvhs9KAOFELZLJTDadIyKAgeks 6kyHSU8YFU9FjlQ6KRWzFDXxSiB4fWZxyyAMHMyqV1w6fZy+4hzrsHQLBX0tA/xbVFiS qJIHXS5OV8Sc6iaOc4wiBax48lOVSq6pMC9pyUUCKG8qY36Gm+jh2++ia0m84xrg/TP2 ZNeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743042523; x=1743647323; 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=OGwrNVh/WZTTtw7uAqgZK0CpG9xq3xfhc8jxsCdvx0E=; b=CyglkdWDSb3kpB40X9UmG8r1mQvb1szpp+8YLTnAtJSOUSZFq3ZPEmn2fyQBA9m8jm t1iA+ls9xMS1XXIJHg9C+WiiJtaqWsQ7pn6g7gexn1rrZWsd97yYIZd/qk/sSZtfYifW 9yVu1YwEWscojqWtVe665MzI1tR1ZkaNxspgSAkHy2h7wQzMrsYJEsF0joxvHfcn1HJi qwG/fs8lQL+JxI3lJQN5fvF4s2/ydncVDTXJmOgzv7nBIZaJzGW37q9Nu8RkL8JVcwqB fXvLUDUgiTe4rFllyWNjzftnjx8PWgI+YlFGaU8osy2tQ9+aKxG3j1UbShoPB/Odvs+k 2amQ== X-Forwarded-Encrypted: i=1; AJvYcCUePxwXGeQVWQ5LZ3KMoSZSRo5NNY3W7lPMY8qNSTxwtaZTLmb1ctJG7gTovd/pAXkdstXd@freebsd.org, AJvYcCUgJXh/7O9FbBZrLoPvrreAOLq0g18z5cseuID1da7fOU5UPYoU0tB1TOoZ6sIVUw7KopQpknuueN6aWoqS4bhq@freebsd.org, AJvYcCV2N4nb1j964WC1O6YpnWSe7EurvHzuNScDlf/VFRTTpifUs9tqp0SWtNb9EZHYV7u+4U6j6anbVRlvsRY=@freebsd.org X-Gm-Message-State: AOJu0YwTdE/fniZ/4ZXbq6RiRLQ11KArGtH78uYt137/8KvPnXKXi8bq UfGGiu+PxcOjncHKJ9A8Z94CnJVhHB1vlsHI9Z5DrS3CM7FqsvMjPsk5LGqxJIL4Bp/enpPxFuZ G9umMneWdCTylXl7iqH2uEns7CA== X-Gm-Gg: ASbGncuQW8eE9uZvx0FTC9XyuuXTjR6XJ//Nf9hRuGYW0L6EmGp6CSaKUub6jsYxPhi B+uL+7JYnGnv8zRC4+ei8q9AStGdOXUE5IpuiD6NePkdqfbJHLt+yEaWFw9FvGZ8krbUpXue+Oa CP+1119dtIs0RWKmrV17JD8UG+EOUgNRve1g8VXxlXkdnwEmZGzUFsLHl6bA== X-Google-Smtp-Source: AGHT+IGh+jwsKkoTC7Jp9KQTmGLXlmHgEYcWxlRtqOWkt1Nuzfdt7SDtAEWE6AOdIamX7fG6p1X/lKtoOuto3dP/KwU= X-Received: by 2002:a05:6402:350c:b0:5e4:9348:72c3 with SMTP id 4fb4d7f45d1cf-5ed8e27b242mr1895825a12.10.1743042522877; Wed, 26 Mar 2025 19:28: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: Wed, 26 Mar 2025 19:28:32 -0700 X-Gm-Features: AQ5f1JrcUWjR-JU3Jt2RYk_XN-QAhpqzkO8QRl65AMNHWFYKKsMKEXUnBsMLaBY Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Andrew Walker Cc: Lionel Cons , Konstantin Belousov , freebsd-arch@freebsd.org, FreeBSD CURRENT , Cedric Blancher 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_RCPT(0.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4ZNSJY13Qlz3RRC X-Spamd-Bar: ---- On Wed, Mar 26, 2025 at 5:36=E2=80=AFPM Andrew Walker wrote: > > On Wed, Mar 26, 2025 at 5:05=E2=80=AFPM Rick Macklem wrote: > > I am now less convinced that a new value for xattr is needed. > > I need to do more testing, but with xattr set to dir and not sa > > (shown as "on" for zfs get xattr), the attributes seem compatible > > and it is just the KAPI which changes. > > > > rick > > Rick, is it OK to serve the same information as an xattr and as a > named attribute over NFS? Good question. I don't have the answer. It seems that it "will work", so so long as the "system attrnamespace" attributes cannot be accessed/crea= ted on the named attribute side, I don't se an obvious problem (see below). > I'm thinking of how this will interplay with xattrs via RFC8276 since > they all occupy the same namespace. The only issue I am aware of related to RFC8276 is size of the attribute data. Right now, you can create a pretty large (as in data size in bytes) attribute using ZFS and the setextattr API, which will not be accessible via the RFC8276 operations. (They are limited to a single RPC to get the entire attribute's data and the RPC size is typically limited to just over 1Mbyte.) --> They can fail now. With named attribute support, a NFSv4 client will be able to read all the data. > > Being able to fchmod named attributes may also present some unexpected > permissions issues with > users trying to access them via xattr interfaces. Yes, access is something I am just starting to test. Sofar I see the owner = of the file (and therefore also the attribute) can access the file no matter w= hat the attribute file's mode is. Access permissions is where I'll be spending time doing testing for the next while. Will it be identical to the FreeBSD extended attribute model? - I suppose we can make it so, but it probably is not so at this time. I think it could be coded such that the mode of the attribute file is ignored and access to the directory via the mode/uid/gid/acl of the associated object is all that is checked. --> This would make access permissions the same as the FreeBSD extended attribute model but might make it less Solaris compatible? (As Alexander mentioned, it would be nice to know what Windows and Mac OSX does w.r.t. this, too.) rick > > Andrew