From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 79mQBIxwdmA7cwEAgWs5BA (envelope-from ) for ; Wed, 14 Apr 2021 06:33:16 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id lc/XOYtwdmCkbAAAbx9fmQ (envelope-from ) for ; Wed, 14 Apr 2021 04:33:15 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id E92801FE43 for ; Wed, 14 Apr 2021 06:33:14 +0200 (CEST) Received: from localhost ([::1]:46860 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lWXDF-000073-Oj for larch@yhetil.org; Wed, 14 Apr 2021 00:33:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35514) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lWXD4-00006k-CN for bug-guix@gnu.org; Wed, 14 Apr 2021 00:33:04 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:49806) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lWXD4-0002pn-1n for bug-guix@gnu.org; Wed, 14 Apr 2021 00:33:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lWXD3-0008BD-UN for bug-guix@gnu.org; Wed, 14 Apr 2021 00:33:01 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#36508: GDM files have incorrect owner after temporarily removing service Resent-From: Brendan Tildesley Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Wed, 14 Apr 2021 04:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36508 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: 36508@debbugs.gnu.org Cc: Mark H Weaver , Ludovic =?UTF-8?Q?Court=C3=A8s?= Received: via spool by 36508-submit@debbugs.gnu.org id=B36508.161837472731380 (code B ref 36508); Wed, 14 Apr 2021 04:33:01 +0000 Received: (at 36508) by debbugs.gnu.org; 14 Apr 2021 04:32:07 +0000 Received: from localhost ([127.0.0.1]:33119 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWXCB-0008A4-8p for submit@debbugs.gnu.org; Wed, 14 Apr 2021 00:32:07 -0400 Received: from mout-p-102.mailbox.org ([80.241.56.152]:15662) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWXC9-00089V-1j for 36508@debbugs.gnu.org; Wed, 14 Apr 2021 00:32:06 -0400 Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:105:465:1:1:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4FKqLk5FWMzQk1B; Wed, 14 Apr 2021 06:31:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailbox.org; h= content-transfer-encoding:content-type:content-type:mime-version :subject:subject:references:in-reply-to:message-id:from:from :date:date:received; s=mail20150812; t=1618374714; bh=ouPL1qs6om xiQMs7gkF+Ue3RkqqmKGDxWSkqSIO7ZNQ=; b=eAp9VdEkykKOE+HGfgoKQBjJhx yryIWbJ1CtU6hG9hIAsb93f/z8RRllTxiP90gTGu81zyNPiAbixre2toJBdudC5A 3Lcvl9QPSmFJZbhjGgvyuWpm5KftRF+bof4C18tapXnbMKE04B4sX0dj+7Bn4IO2 2IE+2CAe/2YoLHfgbFyGXJFeI9L3d0cIZPhA6jJB4828rZSPimQftcKghTpklgXf XqGPBAFe6f5Av10CCe7pAQ8iffyoubgDvlciC8x4xYrk43FyIflvB7myuFs9J3O4 Rxrke7p2NlGZ9Vy5ItX2AK0Bl18F5N84TLmqYViLpcP4INqHyKrvbDMgsrwQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1618374716; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=C62iV6IxQGLQIxbZx1DNdC1AUs0Vor4kHPo/eDxfr2M=; b=XGv7labxwrvcBCvki7nr1izMqCQMd1JxqjqEmfPSMSXirRGd6+74NGoKdY09bkDhwgEoyM 0u++AkanPW/qQK6/uKLvlQtMzNV+cgoYWzGcQ4ll8yMXIjZw4Dmind4mUb/iKr7AjXjcMF frMhzB2AsNZwdHc8oJGHXaPJufOzaLwfNEyrbcWeTnjpWNTTZlJlycta51yhxLyXkikwTJ uWZN/zyXuQyouYdajTcS/3DcROF/hKp5O+hBwJt7Bv5iEli4dZMZIkOK/RAgVT+Fyzw3tL VjeuLMfOQtx3fki8jhLAZYzFTCTa98p8GFmOUyNik3dPj6tw99LxapSCOFa5IQ== X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter04.heinlein-hosting.de (spamfilter04.heinlein-hosting.de [80.241.56.122]) (amavisd-new, port 10030) with ESMTP id fyRO9kQPTyV9; Wed, 14 Apr 2021 06:31:54 +0200 (CEST) Date: Wed, 14 Apr 2021 06:31:54 +0200 (CEST) Message-ID: <461701204.22088.1618374714507@office.mailbox.org> In-Reply-To: <87czuxsya5.fsf@netris.org> References: <20190705083620.lbzu7a33awbymh3d@cf0> <1576552162.14721.1618320275616@office.mailbox.org> <87czuxsya5.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-MBO-SPAM-Probability: X-Rspamd-Score: -6.44 / 15.00 / 15.00 X-Rspamd-Queue-Id: 5CDF017CC X-Rspamd-UID: 553017 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" Reply-to: Brendan Tildesley From: Brendan Tildesley via Bug reports for GNU Guix X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1618374795; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=C62iV6IxQGLQIxbZx1DNdC1AUs0Vor4kHPo/eDxfr2M=; b=la8QQJsPibuTG/bJIpu1w3cIh8hcX8mupZDaxHqiSbBKIqfUTn30VFkXtxp3wgw6HDv2pq LChfqYLMUhNb1cbf6GWtovWdUIgvoIG4+AS8JBdb583I0MaBP/lAEt8DaoFMlk4XZ2CS6f qtgSVLC+stkL1mlXfCRIQy32TzEb1J4bOpz8Ppr79aIuQcdSBeRK13zf9gO19VzQf7xC3l bWWa5Nj9rVRXOJuTrE6y4f+hrEKzF1UbIe0dc6qZ/PzDXsQihdqUHW7uXDJwrYlKvwYqbo w1jXsMxxnAbrVzMbLph2fz8akOQPFKuHXDVKMsp5D9dAXuig2DTd/zs8zz3vbA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1618374795; a=rsa-sha256; cv=none; b=YhZdoA7CAiBkQUgd8Oe5ISh3oQxAwN5oWn1/fNY9WiJ6NUEQm9+dqt9X8+L/5heMLc67ts 85ujujZA3h4+ffs5/g9vkoVJ4qAdgIQ8h4jmVo0QWy0PjP5UC0qTLnjdb/T3CD5Z1hz/ex fqU3/0uDxZU4Y9E8t18MukymXTrz1r0QCSCm43qI68NaSM8MPYIB4mnE6G+evK80ssORUt CkuMXnfjnCV+m8UGQNqOv3NeiYREI7Y3ksCvj7oiRCKclhvOeq87N69r3vBJ7Qbi3XkxTl lsULzqidqtv135U94ZYmc5HJX0Zy2H8g+G0TdJYHWrNHYRslgVZnsEmozIGDKg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=mailbox.org header.s=mail20150812 header.b=eAp9VdEk; dkim=fail ("headers rsa verify failed") header.d=mailbox.org header.s=mail20150812 header.b=XGv7labx; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Spam-Score: -2.94 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=mailbox.org header.s=mail20150812 header.b=eAp9VdEk; dkim=fail ("headers rsa verify failed") header.d=mailbox.org header.s=mail20150812 header.b=XGv7labx; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Queue-Id: E92801FE43 X-Spam-Score: -2.94 X-Migadu-Scanner: scn0.migadu.com X-TUID: lDA1FqtuR7cz > On 04/13/2021 10:51 PM Mark H Weaver wrote: > > > Hi Brendan, > > Brendan Tildesley via Bug reports for GNU Guix > writes: > > > I recently encountered what is likely the same bug. The directory /var/lib/gdm > > had the correct permissions gdm:gdm, but all the files inside had something like > > 973:gdm > > The underlying problem here, which I've also experienced, is that if you > reconfigure your system with fewer users/groups, and then later add > those users/groups back, there is no guarantee that they will be > assigned the same UIDs and GIDs. > > This problem is made much worse by the fact that files may be left > around, e.g. in /var, with the old UIDs and GIDs. > > In your case, I guess that the 'gdm' user was previously assigned UID > 973, but now it has been given a different UID. > > In my case, after reconfiguring to a minimal system and later switching > back to a full GNOME-based desktop system, I found that many files and > directories in /var had the wrong owner or group. Here's what I saw > before I cleaned things up: > > --8<---------------cut here---------------start------------->8--- > root@jojen ~# ls -l /var/lib/ > total 4 > drwxr-xr-x 1 colord colord 40 Mar 28 2017 colord > drwx------ 1 995 978 56 Sep 3 02:10 gdm > drwx------ 1 root root 30400 Dec 25 01:55 NetworkManager > -rw------- 1 root root 512 Dec 25 01:35 random-seed > drwxr-xr-x 1 colord colord 164 Dec 28 2017 sddm > drwx------ 1 tor tor 178 Dec 19 21:28 tor > drwx------ 1 root root 20 Sep 5 01:32 udisks2 > drwxr-xr-x 1 root root 274 Dec 25 01:55 upower > drwxr-xr-x 1 root root 86 Mar 28 2017 wicd > root@jojen ~# ls -la /var/lib/gdm/ > total 4 > drwx------ 1 995 978 56 Sep 3 02:10 . > drwxr-xr-x 1 root root 750 Dec 25 01:59 .. > drwxr-xr-x 1 994 colord 64 Sep 3 02:10 .cache > drwx------ 1 994 colord 54 Sep 3 02:10 .config > -rw------- 1 994 colord 16 Sep 3 02:10 .esd_auth > drwxr-xr-x 1 994 colord 10 Sep 3 02:10 .local > root@jojen ~# > --8<---------------cut here---------------end--------------->8--- > > Given the fact that existing files and directories in /var can > *effectively* have their ownership changed, I think that this issue > could be a security risk. Yes and they could change for any reason under the sun, and so we have no choice but to set them right on service activation. Guix system rollbacks should be a supported feature of Guix, not just a gimmick that falls out of its design. It should be that a Guix user could leave their system for 5 years, and then do a guix pull; guix system reconfigure in the year 2026. Perhaps at that time the new system will break, and then its desirable that they can rollback to the previous generation. So what fixes we put in to Guix services today need to consider not just how files could have changed in the past, but how they might change in breaking ways in the future, within reason. I don't know off the top of my head of any way that can be done other than to have chmod -R gdm:gdm /var/lib/gdm always executed. > > There's some discussion of this issue at , > although I'm not sure that Danny's suggested solution is practical. > > Here's one idea: when activating a system, *never* delete users or > groups if files still exist that are owned by those users/groups. > Checking all filesystems would likely be too expensive, but perhaps it > would be sufficient to check certain directories such as /var, /etc, and > possibly the top directory of /home. > > What do you think Wouldn't that imply that uids could be randomly different on different systems with the same configuration, and then remain statically different permanently? We want as little randomness and moving parts as possible. It's yet another way the system is not actually Functional, but has state. Seems this bug spans 3 or so different bug reports. In http://issues.guix.gnu.org/45571 I commented that Nix uses hard coded id's, sorta like how ports are allocated for a purpose: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/misc/ids.nix Perhaps you are thinking of other kinds of security issues that could be caused that I'm not thinking of. In that case maybe Nix devs have already made the best choice by making them static? ... After all, if the permissions can change, then it is possible another user could actually modify the contents of /var/lib/gdm its self, thereby infecting other users, if for some reason that other malicious user gets allocated that ID. That further points towards static ID's like Nix has as a solution.