[From nobody Tue May 26 23:53:06 2026 Received: (at submit) by bugs.debian.org; 23 May 2026 18:43:59 +0000 X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02 (2024-03-25) on buxtehude.debian.org X-Spam-Level: X-Spam-Status: No, score=-128.6 required=4.0 tests=ALL_TRUSTED,BAYES_00, BODY_INCLUDES_CONTROL_AFFECTS,BODY_INCLUDES_PACKAGE,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FROMDEVELOPER, HAS_PACKAGE,SPF_HELO_NONE,SPF_PASS,USER_IN_DKIM_WELCOMELIST autolearn=ham autolearn_force=no version=4.0.1-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 27; hammy, 150; neutral, 112; spammy, 0. spammytokens: hammytokens:0.000-+--Hx-spam-relays-external:sk:stravin, 0.000-+--H*RT:sk:stravin, 0.000-+--Hx-spam-relays-external:311, 0.000-+--H*RT:311, 0.000-+--H*RT:108 Return-path: <smcv@debian.org> Received: from stravinsky.debian.org ([2001:41b8:202:deb::311:108]:49736) by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from <smcv@debian.org>) id 1wQrKI-000W9t-2k for submit@bugs.debian.org; Sat, 23 May 2026 18:43:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:Content-Type:MIME-Version:Message-ID: Subject:To:From:Date:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:In-Reply-To:References; bh=KgVjujQ+kb1zrGfg4DUCi8HHM4APH6rWQkXZdZHa3/I=; b=vBcae0JWdWnHBrJRIhzqAu+f79 yC1BxZcYrAG2IUzc7Wo3XbX2i86aleLNAb5sJh7lA5aZh5T+abhNfdlKRzLtCucqrabCrJPIvNzLW syQBphqRq397rgMnYHSupFk3wWgDaEpQXrynWEvj7nbrW64ILPxagzbpY08D5vJ2FkSRYYARRWXsG Z7SKza1oxVNWD0Pjd21sLAYI44C3Vob2NMWXdmXhBYHDX/ziji4ub/J3m+enCKT2sBDuv5yFm0gXA HSeDJSsiMIl2g4f+ns8pgIDfa+YqVSGCqdv1d+8uP264GQH9bNbd2aka0r/g8PRJFFxXEs2B7YD8K kovpjWLA==; Received: from authenticated-user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from <smcv@debian.org>) id 1wQrKH-000EGP-2D for submit@bugs.debian.org; Sat, 23 May 2026 18:43:57 +0000 Date: Sat, 23 May 2026 19:43:55 +0100 From: Simon McVittie <smcv@debian.org> To: Debian Bug Tracking System <submit@bugs.debian.org> Subject: systemd: Changes permissions of root directory from 0755 to 0555 Message-ID: <ahH1aw_Z2tHro9op@definition.pseudorandom.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Mutt-Fcc: =.lists.debian/ X-Reportbug-Version: 13.2.0 X-Debian-User: smcv Delivered-To: submit@bugs.debian.org Package: systemd Version: 261~rc1-1 Severity: normal X-Debbugs-Cc: piuparts@packages.debian.org, base-files@packages.debian.org Tags: upstream Control: affects -1 + piuparts base-files Since 261~rc1, the systemd package contains a tmpfiles.d(5) snippet /usr/lib/tmpfiles.d/root.conf which sets the permissions of the root directory to 0555. This appears to have been added in https://github.com/systemd/systemd/pull/41431 upstream, originally as a way to make the system bootable if the root filesystem was mistakenly bootstrapped, untarred etc. onto an existing filesystem that was created with overly-restrictive permissions like 0700. (Conversely, it would also be helpful if the filesystem had started with overly-broad permissions like 02775, which should be tightened.) According to comments on the PR, upstream intentionally chose to use 0555 rather than 0755, as a preemptive hardening mechanism so that if code is running as uid 0 with no CAP_DAC_OVERRIDE, it can't write the root directory (although this likely only provides any hardening in practice if all root-owned files are on read-only filesystem mounts, otherwise root-without-caps can just elevate privileges to root-with-caps by overwriting an executable that root-with-caps will run, such as systemd itself). This all seems like entirely reasonable reasoning, but it has the effect of changing the permissions of the root directory of existing Debian installations, typically from 0755 to 0555, which is not necessarily expected. It also leads to piuparts complaining about / having changed whenever the systemd package is installed and subsequently purged, for example while testing dbus-system-bus-common, which is how I found this. If we want the root filesystem of Debian systems to be canonically 0555 rather than 0755, that seems like something that should be coordinated with base-files and maybe debootstrap/mmdebstrap/cdebootstrap, so that it will be true for all machines/containers/chroots and not just those that have the systemd package? (I'm not sure which component actually chooses the permissions of the root filesystem during bootstrapping - base-files, or the specific bootstrapper implementation that was used.) Or if this change wasn't intended or isn't desired, the systemd package could either not install root.conf, or mask it with an empty /etc/tmpfiles.d/root.conf. smcv ]