From nobody Thu Oct 17 19:35:27 2024 X-Original-To: freebsd-fs@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 4XTyjg6cSzz5ZPYC for ; Thu, 17 Oct 2024 19:35:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4XTyjg4LrWz4fBP; Thu, 17 Oct 2024 19:35:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 49HJZS2Q074450; Thu, 17 Oct 2024 22:35:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 49HJZS2Q074450 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 49HJZRnC074449; Thu, 17 Oct 2024 22:35:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 17 Oct 2024 22:35:27 +0300 From: Konstantin Belousov To: Alan Somers Cc: mscotty@protonmail.ch, freebsd-fs Subject: Re: Should VOP_RENAME fail if tdvp has an IMMUTABLE flag set? Message-ID: References: List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home 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)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4XTyjg4LrWz4fBP X-Spamd-Bar: ---- On Thu, Oct 17, 2024 at 10:58:02AM -0600, Alan Somers wrote: > On Wed, Oct 16, 2024 at 4:36 PM Konstantin Belousov wrote: > > > > On Wed, Oct 16, 2024 at 04:11:28PM -0600, Alan Somers wrote: > > > ufs_rename and ext2_rename will both fail with EPERM if the > > > destination directory has an APPEND file flag set. So will > > > tmpfs_rename. However, tmpfs_rename will also fail if the destination > > > directory has an IMMUTABLE flag set. That's inconsistent. It seems > > > to me that tmpfs's behavior is more reasonable. Does anybody know why > > > ufs and ext2 have always allowed rename even if the destination > > > directory is IMMUTABLE? For that matter, does anybody know the > > > rationale for preventing it if the destination is APPEND? > > > Intuitively, I would think that an APPEND-only directory would allow > > > new entries. And I don't see any checks for APPEND in ufs_mkdir, > > > ufs_link, or ufs_create. > > > > For UFS, IMMUTABLE is checked on lookup. Search for 'RENAME' in ufs_lookup.c > > and following call to VOP_ACCESSX(). > > That makes sense. So an IMMUTABLE check in ufs_rename wouldn't be > wrong, but it would be redundant. > > > > > APPEND for UFS directories is a strange idea, for instance, does the directory > > compaction breaks append-only? > > I agree with olce@ on this one. Directory compaction sounds to me > like an implementation detail. But does the re-ordering of the directory entries counts against append-only? Adding a new entry could occur in the middle of existing entries, if there is an unused block. This would at least change cookies and the order of returned dirents. Another question, if the target dirent already exists, and rename would rewrite tvp inode number, is this fine for append-only? > > BTW, the motivation for this discussion is that mscotty (CC'd) is > currently working on implementing file flags within fusefs. We're > trying to decide exactly how to enforce them, following UFS's lead > where possible. > > -Alan