From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id yO0SHvuBeGCTeQEAgWs5BA (envelope-from ) for ; Thu, 15 Apr 2021 20:12:11 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id SDKzGPuBeGA8DgAAB5/wlQ (envelope-from ) for ; Thu, 15 Apr 2021 18:12:11 +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 BA72427FF5 for ; Thu, 15 Apr 2021 20:12:10 +0200 (CEST) Received: from localhost ([::1]:40990 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lX6TJ-0005La-Es for larch@yhetil.org; Thu, 15 Apr 2021 14:12:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46266) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lX6TC-0005LP-Ck for bug-guix@gnu.org; Thu, 15 Apr 2021 14:12:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:55842) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lX6TC-0003dJ-4x for bug-guix@gnu.org; Thu, 15 Apr 2021 14:12:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lX6TC-0008OK-0g for bug-guix@gnu.org; Thu, 15 Apr 2021 14:12:02 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#36508: GDM files have incorrect owner after temporarily removing service Resent-From: Mark H Weaver Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Thu, 15 Apr 2021 18:12: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: Brendan Tildesley , 36508@debbugs.gnu.org Received: via spool by 36508-submit@debbugs.gnu.org id=B36508.161851027032192 (code B ref 36508); Thu, 15 Apr 2021 18:12:01 +0000 Received: (at 36508) by debbugs.gnu.org; 15 Apr 2021 18:11:10 +0000 Received: from localhost ([127.0.0.1]:39155 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lX6SM-0008NA-4Z for submit@debbugs.gnu.org; Thu, 15 Apr 2021 14:11:10 -0400 Received: from world.peace.net ([64.112.178.59]:40658) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lX6SK-0008Mx-AI for 36508@debbugs.gnu.org; Thu, 15 Apr 2021 14:11:08 -0400 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lX6SE-0006ts-3P; Thu, 15 Apr 2021 14:11:02 -0400 From: Mark H Weaver In-Reply-To: <461701204.22088.1618374714507@office.mailbox.org> References: <20190705083620.lbzu7a33awbymh3d@cf0> <1576552162.14721.1618320275616@office.mailbox.org> <87czuxsya5.fsf@netris.org> <461701204.22088.1618374714507@office.mailbox.org> Date: Thu, 15 Apr 2021 14:09:17 -0400 Message-ID: <87pmyvifmf.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain 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" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1618510330; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: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; bh=gbSidReC77rDIEB/wC/Igr4BMwAFE3EQX7lGJQogtYw=; b=IAYuyfJJGqNg2qfY/xCVqI80XDVeDrffBX4Tqcy6W3vo8SMBdKI3fetkaTsvBOtyER3vDu qYDEDRn0Abt11+jofiPeYjcdXpd1oWvtZTTSdeSviHBWkN4buFRpdJRWmCtb3KKfGZOVfi 2clgXN6YsaHhhKO/h3/bIYcnfrVGokhY4rMBxcswKMrcwRAV0ysgHgRV8mTglAesLxftJZ V4lubKz8ljy1h+yrjXzD0zcJk1qB4uuG8bbIvV9HhWMkjILsO04/UVJvBtM2uKgVf5m1p1 AwyzOHhvUWG+kaliJqiQ/Nj/IvyApE4tAgHyrlBqC9NKVVBSa6sHkaaYkvzbHQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1618510330; a=rsa-sha256; cv=none; b=Wpfbn39vOf0HGedi8TeFH6SfCDbxgaiVeQKauTqeENlmO1mad6ygxzZf3hR/2J2qmF6/yg ObuBckB5RiT3/ldWiePwqlXQswEJ8bn6I7mJwxN/7c+zJfQxxpLCcUkTGKlnF2ITcZ3ocp qE5A4AG6W15PNcd22/nN/pXQvKCU9fbSmSk0ZHiWbSl/GQ/P/5Lr0TDevPA8UBhijOFI5F sQvnaQtklrRWN9v9v/S861lpaCrdnQGOgZv3OhN8eVId184cJ/fBHOqKag0N5H8+oe2vlJ 7qK0r2Aw0F3XYRIg6ItbDqSp86JDrBQxP6b1vNsqmVNIgy1+pn4/W1GhIURBxA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; 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.44 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; 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: BA72427FF5 X-Spam-Score: -2.44 X-Migadu-Scanner: scn0.migadu.com X-TUID: OE2Yv6xRni8g Hi Brendan, Brendan Tildesley writes: > 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. This sounds like a good set of goals to strive for. I'm not sure that Guix, on its own, will be able to achieve reliable 5-year rollback. I think that would require _all_ software in Guix that maintains mutable state on disk to gracefully support downgrading to a version from 5 years earlier. Nonetheless, Guix can certainly do its part to try to ensure that multi-year rollbacks can work, and I agree that it's a good thing to keep in mind. > 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. It's a good thing to keep in mind, yes. > 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. I'm not necessarily opposed to doing that, at least as a temporary workaround for GDM, but I don't think this is a satisfactory solution to the larger problem. A few points: (1) I don't think we can assume that all files owned by a given user will be in that user's home directory, especially for "system" users. (2) I also don't think we can assume that all files in a user's home directory *should* be owned by that user. Even if it's true today, it might not be true tomorrow. (3) Groups don't even have home directories. > On 04/13/2021 10:51 PM Mark H Weaver wrote: >> >> 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? Yes, and I agree that it's suboptimal. > We want as little randomness and moving parts as possible. It's yet another > way the system is not actually Functional, but has state. Agreed. Danny's suggested solution (UID = hash username) is clearly the optimal approach in many respects. It has the nice properties above. The practical problem I see with Danny's approach is that in order to make hash collisions sufficiently improbable, our UIDs and GIDs would need to be much larger than the 16 bits that is widely supported by POSIX software. With 16-bit UIDs, the probability of a collision would be 1.85% with 50 users, and 7.28% with 100 users. To adopt this approach, I think that our UIDs and GIDs would need to be at least 31 bits. These are the problems I see: (1) It's unlikely that all software in Guix robustly handles such large UIDs/GIDs. Desktop systems with UIDs/GIDs larger than 65533 have not been widely tested, as far as I know. (2) Even with 31 bit IDs, the probability of collisions would still be uncomfortably high when large numbers of users are present: with 10k users, the probability of hash collisions would be about 2.3%. (3) We'd need a transition plan for users' existing file systems. (4) It would be aesthetically unpleasant for our UIDs and GIDs to be random-looking numbers with 10 decimal digits. > 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. I'm not sure what you're getting at here. The only security issue I've raised so far is that ownership of files can _effectively_ be changed when removing services and later adding them back. For example, in my case, 'colord' ended up being the owner of files in /var/lib/gdm. > In that case maybe Nix devs have already made the best choice by > making them static? That might well be true. At the present time, this is the option that seems most appealing to me. One possible approach would be to add a field to our 'operating-system' record that explicitly specifies a total mapping from user/group names to UIDs/GIDs. It could either be a procedure (to support Danny's hashing approach with its nice properties) or possibly also an alist for convenience. If any entries were missing, it would raise an error. One risk to this approach is that users could accidentally make a mess of their system if they made a mistake while changing that field. What do you think? Thanks, Mark