From nobody Wed Oct 16 22:11:28 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 4XTQDG1mLZz5Z48y for ; Wed, 16 Oct 2024 22:11:42 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) (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 4XTQDF3YgRz4FmR for ; Wed, 16 Oct 2024 22:11:41 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=asomers@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none) Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-5c957d8bce2so175965a12.2 for ; Wed, 16 Oct 2024 15:11:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729116700; x=1729721500; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=4rk87g9ffFF/ieDjHxEb+40J52/a5Slov7KkFlbQdUo=; b=deJVN3gHvGL0K6b1vwrnwzH4s0iDsEKNG3BPsiHsb1Cm9ljxeux/3+l45fN0V8qwWL ByYtRI5KNLhkLvZYamDsFpznH+cK7Xs6wbldoF44fzklyzE2efQ03JZWibgdikmH8M7z ObnYA99ERzTkKpHMFVPWVGWkUPiYYIkt7LRuCZ8DH3yp7aAbHQHEOkfb4Zq9PFdg+dQI duc7eTHEn/8VVs7OnNWrQHLOnhwPYRRQsEehsYesl29qEB59Kmmiuux5/7XRSaDZA7hX CgABiBZHLcgGHxVDOAHhDtwm1yGC4Kal3S/sC8TdQtql/VSHlPwxWWZAE4XM71UnxhBH pLTA== X-Forwarded-Encrypted: i=1; AJvYcCW/X/p9Akl93UjyzzRLnW27mYtkgoxb/KQ02THDBfic/d/unCRaQD/OkJHD3hE99WB7zh9yy6owVN0x@freebsd.org X-Gm-Message-State: AOJu0Yz2mkG5I31bX1podOdeFL/8648P7hqRwz7Xz9SfsV0f3UYrLLHU 7NhM2Tuv6P7E9QNNPxKx666AI5lq1x4ig8x46Q1/iC9exDDxPAy+jmSAtqH4tDXZ5QkIDo9yy7O M3PVHtzQ74uqDNB3CWG4cr5YD6M/0tw== X-Google-Smtp-Source: AGHT+IFdEQV6o6xXoHI3+f7tb1WStJSw8UICSiwFKLFHwZSFnH6Eb9P1ikIt88DmBv+3SzPfBb7cKTPPMWB2M/omB0I= X-Received: by 2002:a05:6402:34c8:b0:5c9:99a2:f71 with SMTP id 4fb4d7f45d1cf-5c999a210fbmr3212564a12.15.1729116699887; Wed, 16 Oct 2024 15:11:39 -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 From: Alan Somers Date: Wed, 16 Oct 2024 16:11:28 -0600 Message-ID: Subject: Should VOP_RENAME fail if tdvp has an IMMUTABLE flag set? To: mscotty@protonmail.ch, freebsd-fs Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-1.83 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.93)[-0.929]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; FREEFALL_USER(0.00)[asomers]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-fs@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.41:from]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.41:from] X-Rspamd-Queue-Id: 4XTQDF3YgRz4FmR X-Spamd-Bar: - 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. -Alan