From nobody Sun Mar 09 23:19:48 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 4Z9wwf51qqz5pQGg; Sun, 09 Mar 2025 23:20:02 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 4Z9wwd50mwz3rx6; Sun, 09 Mar 2025 23:20:01 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-5e6c18e2c7dso1002504a12.3; Sun, 09 Mar 2025 16:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741562400; x=1742167200; 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=ma4kbwchYIwuaZattNDuHHdn+zQPt6poElqhFzg2Sa8=; b=JwtBZ0zn9/YLZRbzwruCtZL6TWzOCglSRZrwGyyAJdjrnqL5SC2tgRCs34FgGCtwwy K6xMHBcKsH9tDO1y5yL9VP1K199k793IqVidmZQ/KGmmj13IsFeNhtraFb99Y204DYCg fPk8yMf6BaGJps1d3sepoJnEoKrnF5cEPdSyRJGh4vNIufbNod1374xrFo/WMeHwFcTa TuOq2xNCNZk5vqpRFDcrUQsJma0OOo1/bAbG4NKzckoASLSx7wljsgY3sITjiBG4L7DJ OvqQzPHuUMpgrrwmqD6wKCrhn3Fa3FkKBU535CzH+mL6hApGTrnLgFfv3CPGNa6gHJeO Trwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741562400; x=1742167200; 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=ma4kbwchYIwuaZattNDuHHdn+zQPt6poElqhFzg2Sa8=; b=PiIQln0oAIeb9q4ZEGVldZ99Z9slMg6i7C/2P6MA4OXKZLm5N3aWdJmmXfKQX078At 8CvBuo2PcvASFLi5Qo9v5+40RwOlPSnFYttt//w2zRmuQOoLUCcckQYljXkI/33IqIZr N6jf+t1wMMugd0rbyHmqTJWhCHL3jByx5oKaNhx8S1as/3VmjGVIsKFRw6ETbUJ8yG6I pb6Em5mlfEkZc263bJxknAqhNkPa5H3JmI+IMcKwG3d5K+P30BXBBmw0jDF1aTB6S5sL DemqxYBoQZGA+yys+s85liT5+y5EvFhxFrVu0ADJl+n0BVpAc/zqw9qaA4n3G+8ivJRq j2AQ== X-Forwarded-Encrypted: i=1; AJvYcCV6ApYHwAzgoYSIdGL9+VRL4y1oJwg4dR6yslupwc/DWISU+impVzrqjJvpgOIEKCJ3WrfneLfQcOQ/ZDU=@freebsd.org, AJvYcCWSkdLHY6/an9aFGEPo/YY/SV4+DY4BsQCyGQCCGY/4/b0qFdq/nc+OF7VgPzfEQlBLdhJnI7G0rQCoxvZ8GR/9@freebsd.org X-Gm-Message-State: AOJu0YwOPKOOeg2Nu1iZaV2CSF6uoNaXyagcz9hvFY14/K+5V2YqhrPz 7RuxbWI+DFX2b5jJ5znUsBmXrIu/3TZ51mMZUfD4tRrU9VegpD/2UwE7tASgrvCoqecOWheOGmH Cvoqb0g479zOBTfj0pKSJSNvhDw== X-Gm-Gg: ASbGncsFr9rb8op3PCb9TQJLq5Ou3BOV20hTcx6Ds+fNa0Ts9SRjgkhVrimtIaM5v58 TWr7edABawddWVV9kTYqYCZV9iXRPUfr2gw7K9P0qUISjlEzTvqFbD91lFdTKOptAceWCgBgfXJ 9IFoT4HiJr+OJUXGAVutxn0Kv8Z2OZB9sz5KKGJzTaAI9MWSKonYhjlPKi X-Google-Smtp-Source: AGHT+IF+hSKJZ8ukfUKBrD4lsTAgKdQCW2fTzApRxcRX13CmCxezAXKBbv1spsjIRrv8toBvdxzOFe5uk+Tsm2heVmg= X-Received: by 2002:a17:907:1b05:b0:ac1:e881:89a7 with SMTP id a640c23a62f3a-ac252737ef2mr1198400566b.6.1741562399493; Sun, 09 Mar 2025 16:19:59 -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 16:19:48 -0700 X-Gm-Features: AQ5f1Jog-vsJQhxeI6DnaP62EhYriflet6A3_uzosbAqX9RkyeM029YOmEcV88c Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Andrew Walker Cc: Konstantin Belousov , 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: 4Z9wwd50mwz3rx6 X-Spamd-Bar: ---- On Sun, Mar 9, 2025 at 11:35=E2=80=AFAM Andrew Walker wrote: > > On Sun, Mar 9, 2025 at 8:24=E2=80=AFAM Rick Macklem wrote: > > > > On Sun, Mar 9, 2025 at 5:46=E2=80=AFAM Andrew Walker wrote: > > > > > > Out of curiosity, how are you preventing users from creating / writin= g > > > xattrs with the `system?` name prefix. In ZFS on FreeBSD IIRC this > > > prefix is used to determine whether the corresponding attribute when > > > accessed via the extattr interface is in the user or system > > > namespaces. > > A couple of comments... > > 1 - My current thinking would be a ZFS fs would be configured for one > > or the other (mixing them is weird as noted by the next comment), > > There is currently the xattr property that can be set to "dir" or = "sa". > > 2 - I haven't looked at system space FreeBSD attributes yet (I will), > > but when mixing them, you can get two attributes with the same nam= e > > showing up in the named attribute directory (the open gets the nam= ed > > attribute one). I haven't yet figured out how to get rid of the du= plicate. > > 3 - I assume the patch could include code that excludes "system.xxx" na= mes > > from the directory. (I'll do some testing.) > > > > > I vaguely recall some people may have patched the FreeBSD > > > samba server for instance so that it writes security information > > > related into the system namespace when samba is configured as a domai= n > > > controller so some care needs to be taken with namespaces. > > > > > > You may also need to potentially restrict ones with `security.` and > > > `trusted.` prefixes in case the ZFS data is replicated to Linux > > > systems (because those are privileged namespaces and it may introduce > > > a CVE). > > Thank for the info. I didn't know what Linux does. > > > > rick > > Rick, one other thing to maybe consider is the size of attributes that > you allow to be written via this special open flag. You can > potentially write an attribute that when accessed via extattr will > cause malloc failure because it will basically go OOM. For example if > you create a 30 GiB attribute in the ZFS attr dir, then accessing via > extattr will require allocating a 30 GiB buffer. So you'd probably > want to limit to something like 2 GiB max per attribute (which is what > we do in TrueNAS). I assume you are referring to accessing the attribute via getextattr? One of the main reasons people want the Solaris kind (you seem to call them streams?) is avoiding the size limitations related to FreeBSD (or Linux) extended attributes. I do know that FreeBSD allows pretty large ones for ZFS, but the NFSv4 crowd is against accessing extended attributes (not via named attributes) larger than Kbytes. I'm surprised you allow 2Gbytes for TrueNAS, since the limit for the NFSv4 extension is around 1Mbyte. (RFC8276 specifies the NFSv4.2 extension for Linux style extended attributes and the getextattr reply needs to be in a single RPC, which is normally limited to about 1Mbyte. There is talk of increasing this to 8Mbytes, but I don't know if Linux has gotten there yet.) rick