From nobody Wed Oct 16 22:36:30 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 4XTQn85QSVz5Z57x
	for <freebsd-fs@mlmmj.nyi.freebsd.org>; Wed, 16 Oct 2024 22:36:44 +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 4XTQn739Mgz4HJk;
	Wed, 16 Oct 2024 22:36:43 +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 49GMaU6r035603;
	Thu, 17 Oct 2024 01:36:33 +0300 (EEST)
	(envelope-from kostikbel@gmail.com)
DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 49GMaU6r035603
Received: (from kostik@localhost)
	by tom.home (8.18.1/8.18.1/Submit) id 49GMaUmg035602;
	Thu, 17 Oct 2024 01:36:30 +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 01:36:30 +0300
From: Konstantin Belousov <kostikbel@gmail.com>
To: Alan Somers <asomers@freebsd.org>
Cc: mscotty@protonmail.ch, freebsd-fs <freebsd-fs@freebsd.org>
Subject: Re: Should VOP_RENAME fail if tdvp has an IMMUTABLE flag set?
Message-ID: <ZxA_7pW8Z_VPbBYn@kib.kiev.ua>
References: <CAOtMX2gRv9PviMdEjqvpxGFmDd39c13kmwNnkvf4QS2L-YH=+g@mail.gmail.com>
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-fs
List-Help: <mailto:freebsd-fs+help@freebsd.org>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Subscribe: <mailto:freebsd-fs+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-fs+unsubscribe@freebsd.org>
Sender: owner-freebsd-fs@FreeBSD.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAOtMX2gRv9PviMdEjqvpxGFmDd39c13kmwNnkvf4QS2L-YH=+g@mail.gmail.com>
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: 4XTQn739Mgz4HJk
X-Spamd-Bar: ----

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().

APPEND for UFS directories is a strange idea, for instance, does the directory
compaction breaks append-only?