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> In-Reply-To: <CAOtMX2gRv9PviMdEjqvpxGFmDd39c13kmwNnkvf4QS2L-YH=%2Bg@mail.gmail.com> References: <CAOtMX2gRv9PviMdEjqvpxGFmDd39c13kmwNnkvf4QS2L-YH=%2Bg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZxA_7pW8Z_VPbBYn>