From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id uJWVDUUSGWROEQEASxT56A (envelope-from ) for ; Tue, 21 Mar 2023 03:11:17 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id ANpeDUUSGWSF9AAAauVa8A (envelope-from ) for ; Tue, 21 Mar 2023 03:11:17 +0100 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 E9CF9F1D5 for ; Tue, 21 Mar 2023 03:11:16 +0100 (CET) Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1679364677; h=from:from:sender:sender: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; bh=Ahg47O0hnnAMw/1R8kF0Gxd/hzAppcGS/Irqtm2SY5E=; b=T8j3lWUjYnrHba6HoxQWkfG5afGnxLYjP6kgXJTks+lA5tbNZOurvuAWBk7iS2v96fKPEq gUnd+65L/wLKZqe350k3sxYNEywZl0USX5MCYbD/kmPa/nS0TgsTe273UI4b70iI1FfKoU bX99i/YBDn35P6G8xLXnwEklOqaQ6vVKaPwREKdSnv57mxKcnLqjqzCc8qsvzDGtBRik/y mtPoqPXDYO0EgRBX5IKJ9vrMhn84p0RyvSghxqc/0BwFkcJH+k9qD5gwj1iiRsF2W9kbqD 3XmOjYkBdW6uuYlxVrqz8xl657xdagl6UbGexR1oHPBiTeWzdbyaYYadyhA+cA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1679364677; a=rsa-sha256; cv=none; b=ZhowDFRVQpxEjsqK39Y76i9CR7VwZIiA8/JjKuLZarLnKgKQSp9yl2p8ckzUZxPFhBRJ4d O1c/qiTmGRwJqFvmShObR1sC40wU9epbyUSTzx/vIGSdE+tZTMhxTN0Z1vYrOhvaBSTWdY u3S0eHypLHssihLpsbSGJlQVMKLEkpT+hl30/KZRojtaBjU6dgYFbR+oY4NQ9r4pOtvJzj l96C5/A1GFJv33cUQStOWKkuF1dlTobkve2T6YkgHXugVoVOvuw0CRgYUMBfXC7i+xBJKc TBBIzEh5co6WDqytaETXd9YNaAzG35srvzFwcy7eiPQIM6VR5E+nTjH8HX6OrQ== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1peRSs-0006sJ-8K; Mon, 20 Mar 2023 22:11:06 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1peRSq-0006s4-E5 for guix-patches@gnu.org; Mon, 20 Mar 2023 22:11:04 -0400 Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1peRSp-0005tT-3H for guix-patches@gnu.org; Mon, 20 Mar 2023 22:11:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1peRSo-0007bY-Im for guix-patches@gnu.org; Mon, 20 Mar 2023 22:11:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#62298] [PATCH 7/8] services: mpd: Use user-account (resp. user-group) for user (resp. group) fields. Resent-From: Bruno Victal Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Tue, 21 Mar 2023 02:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62298 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Liliana Marie Prikler Cc: ludo@gnu.org, 62298@debbugs.gnu.org, maxim.cournoyer@gmail.com Received: via spool by 62298-submit@debbugs.gnu.org id=B62298.167936462229180 (code B ref 62298); Tue, 21 Mar 2023 02:11:02 +0000 Received: (at 62298) by debbugs.gnu.org; 21 Mar 2023 02:10:22 +0000 Received: from localhost ([127.0.0.1]:57237 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1peRS9-0007aa-N6 for submit@debbugs.gnu.org; Mon, 20 Mar 2023 22:10:22 -0400 Received: from smtpm3.myservices.hosting ([185.26.105.234]:57230) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1peRS6-0007aM-UV for 62298@debbugs.gnu.org; Mon, 20 Mar 2023 22:10:20 -0400 Received: from mail1.netim.hosting (unknown [185.26.106.173]) by smtpm3.myservices.hosting (Postfix) with ESMTP id 1FD1520D05; Tue, 21 Mar 2023 03:10:16 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail1.netim.hosting (Postfix) with ESMTP id 93D438009A; Tue, 21 Mar 2023 03:10:16 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail1.netim.hosting Received: from mail1.netim.hosting ([127.0.0.1]) by localhost (mail1-2.netim.hosting [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wuH8D5qUOdXC; Tue, 21 Mar 2023 03:10:13 +0100 (CET) Received: from [192.168.1.239] (unknown [10.192.1.83]) (Authenticated sender: lumen@makinata.eu) by mail1.netim.hosting (Postfix) with ESMTPSA id 81F0D80098; Tue, 21 Mar 2023 03:10:13 +0100 (CET) Message-ID: Date: Tue, 21 Mar 2023 02:10:05 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Content-Language: en-US References: <6e1da37de3839d56546389924ce47b4563d05d94.1679332019.git.mirai@makinata.eu> <27ddb1989f281cee887c903955cc793fc34bd1ab.camel@gmail.com> From: Bruno Victal In-Reply-To: <27ddb1989f281cee887c903955cc793fc34bd1ab.camel@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: X-Migadu-Queue-Id: E9CF9F1D5 X-Spam-Score: -1.35 X-Migadu-Spam-Score: -1.35 X-Migadu-Scanner: scn0.migadu.com List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: guix-patches-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-TUID: JVNGVQMlvlXq Hi Liliana, On 2023-03-20 19:33, Liliana Marie Prikler wrote: > Am Montag, dem 20.03.2023 um 17:07 +0000 schrieb Bruno Victal: >> Deprecate using strings for these fields and prefer user-account >> (resp. user-group) instead to avoid duplication within account- >> service-type. If a string value is encountered, it is ignored and a >> predefined variable is used instead. This is essentially a rollback >> to how it used to be before >> '5c5f0fc1135ff15f9c4adfc5f27eadd9a592b5d1'. > I already wrote this in private in IRC, but falling back to a constant > when a string value is given is very silly. IIUC the reason to do so > is because you would need to sanitize the user account and group at the > same time so that the former has access to the latter. > > > I think it's possible to use one of the following approaches to get a > better result: > 1. In (mpd-accounts), check if the user group equals the group name and > raise a warning (or error) if not. > 2. Use a special unique symbol, e.g. (make-symbol "%mpd-group") to > denote the value to be lazily inserted by the serializer. After giving some thought to this, IMO I think it's simply uninteresting for these fields to accept string values. Prior to the 5c5f0fc1135ff15f9c4adfc5f27eadd9a592b5d1 refactor, the names were hardcoded and the refactor allowed them to be changed. But with the observed interactions in [1], it became clear that: 1. This service isn't meant to be used with a non-interactive user, a home shepherd service should be used instead. (granted the bug isn't due to this, it merely surfaced up here. Setting group to “nobody” would have also caused the same kind of problem.) 2. Accepting strings was deemed undesirable since it then results in a “race” between user-accounts from operating-system and account-service-type extensions (or even among the extensions), with the winner getting to “build” the account as it sees fit. In the end, the daemon requires a user-account + user-group to work (unless you're in the mood for running it as root?), so something still has to be made. The choices that I think make sense for user/group fields are: 1. Leave it with a default value. The service creates what it needs. 2. Give it a user-account/group. This is considered an _advanced_ use-case and it's highly likely (though not mandatory) to be used within a let-form. You use this when you need fine control over the account properties. Accepting strings is simply uninteresting (or bad) since: * A string doesn't uniquely identify an account and results in buggy behavior [1]. * Since the string values are only used to set the 'name' of the user-account/group records, which is specific to the service as they're created within the mpd-account procedure, it's simply setting a vanity value. It's as interesting as allowing the filename in (mixed-text-file "mpd.conf" ...) to be set by the user. * It's clearly unsanitizable since it would require accessing other fields. Monkeying within (mpd-accounts) with special symbols just obfuscates the code with no clear benefits to be had, in addition to defeating the point of having a sanitizer in the first place. I fail to see the utility in ever accepting strings here for what amounts to a vanity change in 'ps aux' output. Maybe my imagination is failing here but I really don't think it's worth the trouble to support strings here. This vanity change is still achievable with some extra-typing if someone really wishes it. As such, I think the best course of action is to simply use user-account/group record objects from now on, with string usages deprecated and properly communicated to the user that they're not supported and are ignored. (a non API breaking change) [1]: Cheers, Bruno