Re: Should VOP_RENAME fail if tdvp has an IMMUTABLE flag set?

On Thu, Oct 17, 2024 at 10:58:02AM -0600, Alan Somers wrote:
> On Wed, Oct 16, 2024 at 4:36 PM Konstantin Belousov <kostikbel@gmail.com> 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