From nobody Thu Oct 17 16:58:02 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 4XTvDB0Zzhz5ZD5l for ; Thu, 17 Oct 2024 16:58:18 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) (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 4XTvD941N7z48KV for ; Thu, 17 Oct 2024 16:58:17 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-f50.google.com with SMTP id 4fb4d7f45d1cf-5c937b5169cso1884901a12.1 for ; Thu, 17 Oct 2024 09:58:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729184295; x=1729789095; 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=XK+2veto7BRc06Fs/Cfjyiu5N5CCdjqkEMZjZFzlW5U=; b=lFZ32E4iS/+1dMUyCgP9jtBwL5x/J55TEkkIBS+LvGk21ljkrg17T7QHsVRvgEuIqL kVCviCc0Ketdt+CKvbHYVNxiy1BTXbI23uEdkyWItGJoKGlNra9ntqwBUuS1F809todI nP4n95QTMwQPlVgMxI931YMwhh//dzWg8bmQS5H8+yEmObiOxu/2t3VHqK4+G9KrC/f4 gYk/O2MP3oS6k55HvmXhzJ7OIdUBpztMHXdY3F1bRAO3Q6ri+0hVinUTkg9tIc+1VL40 Aa9vjp4bo9ildMfZqQ/F7qn9uOIJK/wgnpCG/zWyF1TE2vSkbuQRS0HXA5VUTzHq0CXF unIw== X-Forwarded-Encrypted: i=1; AJvYcCWxE2BQzLY0/6JOR4P1E2U2ba52Ucr1WQeszCGp6eCMJwZ4UyqyTWeaKJLU2aoVBwsxuRdn3Yx067ra@freebsd.org X-Gm-Message-State: AOJu0Yzmjb3kHeKfas92486yH1v/mxKCMUf83JdJgESQqvlrOXgQiGPG wZjNPeDNG9Q1zKzW7HNTvi7sjGNuHQYc1qm6l4n3fvSwEwxN0juWLNpBC8k5kepnhI/ZHll6d6H u7w8mWba5vSMnChE1qBiU+IT6edA= X-Google-Smtp-Source: AGHT+IFbQydcxpshnO2CdztmQt3qifwuTJOjNLKoW2Uk0CyqUQvBa7nN1KhvN78ExRscxjtoC5c4LPECjA6e+XE68wg= X-Received: by 2002:a05:6402:26c3:b0:5c9:7f41:eb1b with SMTP id 4fb4d7f45d1cf-5c9a5a56109mr4381407a12.17.1729184295089; Thu, 17 Oct 2024 09:58:15 -0700 (PDT) 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 References: In-Reply-To: From: Alan Somers Date: Thu, 17 Oct 2024 10:58:02 -0600 Message-ID: Subject: Re: Should VOP_RENAME fail if tdvp has an IMMUTABLE flag set? To: Konstantin Belousov Cc: mscotty@protonmail.ch, freebsd-fs 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)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4XTvD941N7z48KV X-Spamd-Bar: ---- On Wed, Oct 16, 2024 at 4:36=E2=80=AFPM 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_look= up.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 dire= ctory > compaction breaks append-only? I agree with olce@ on this one. Directory compaction sounds to me like an implementation detail. 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