From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id oOzdFzOqyGYCuwAAqHPOHw:P1 (envelope-from ) for ; Fri, 23 Aug 2024 15:26:43 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id oOzdFzOqyGYCuwAAqHPOHw (envelope-from ) for ; Fri, 23 Aug 2024 17:26:43 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=debbugs.gnu.org header.s=debbugs-gnu-org header.b=vMgUORv0; 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=1724426803; 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:dkim-signature; bh=z+HQDy2QfZSCwc3siZ97i9ntKpxAkmf0b2N8QJ4TRXg=; b=AU5znPd2IcCburEBwz5/57ruU4Ig1/5XnVGY7M05LXECz1YFCXHd0bNIS7VqZPDUizUNAq sClBbPTmvbgRYaO5zF9tabTkMls9zDgw6psw/BpFFei7+hXS1bitJy2NOoIXa2n5nhbS2f jnYqggMr7lBbUygJVgZ1R2IheAHWWa7ZhpthfZsIIEebY99jZpsxJ5QHYQpONN1qNEJx+1 Os65GbYrE0/fEZv3Owt4Ts24Rlfh2KsUQeezjSvSHDlk6GGv1qpDmutorbI3CStVeH4gcP k1wTmUfvrAi0RCW/EESuuUxxfMTGTntf+5NyVICWfdJE7Utj0r2VYR3EQJHFFQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1724426803; a=rsa-sha256; cv=none; b=p80fNuMLFjTMgZSk+eQ5EykPLTiPsZZ5CkR7TbxawoiHCzjg4IUv0oX85Bjd4vIs+QfW3L JIUWRB1vHzvuAvLdSh0yBIftV9m0z7HSqWal7IMlcpbrcNNJtmcfCad6IEMRPJQXiFqzQr 7N93RDUb9Z44LXDihICWkq1XJK6TbWJQeMQjYOU6ZY60p4L4nTYqOICzSCjCgMxwyFJ8UR XkxC5l62v2zAbzkd55AznRKX1CtqyfCPNs2HTkaKjmtoPmv7j0LGiLsJEfCWzFJtSxjTWk NkBzJIIWnJs+orX5JS+z7ZXkhVwefVqgtcvlows8g2rGNe3t84yu85x+7Kag2g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=debbugs.gnu.org header.s=debbugs-gnu-org header.b=vMgUORv0; 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" 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 CF4AB726AC for ; Fri, 23 Aug 2024 17:26:42 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1shWB7-0007Pk-IN; Fri, 23 Aug 2024 11:26:17 -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 1shWB4-0007PU-Nd for guix-patches@gnu.org; Fri, 23 Aug 2024 11:26:14 -0400 Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1shWB4-00037o-EW for guix-patches@gnu.org; Fri, 23 Aug 2024 11:26:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=In-Reply-To:From:References:MIME-Version:Date:To:Subject; bh=z+HQDy2QfZSCwc3siZ97i9ntKpxAkmf0b2N8QJ4TRXg=; b=vMgUORv0Xq/3ipEseGT9JbcJSnUvNkIEWtpDbJQzlaH67aI/K7zkU7yc4eBObJRfke8enOOayiBhTbaTaJvxah8wUhkF/IaQ4IXy+KbJlDK0euHhzW+75KORmhzJ4VCYNX+qtBmWQbtG73ZvfY7pwup9gEYrJpOpbKYrhjznNfWuwduJKrj8d+MLwTjBGgwbbiqk3WS5iYMKqxAcf+5TqWLlcR0o0MtA2pVd0Ouu7es81JJH+Wi8C6buyukz8eIr3mWBEjpfunNm/BW/IBFkqujsKuV1dmvZzwGUnq2xcvMNu/EVa0XgTMbUR0m8XTEdjehD04B3sJ++Vz49L/YpRg==; Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1shWBp-0003ha-MM for guix-patches@gnu.org; Fri, 23 Aug 2024 11:27:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#72398] [PATCH v2] services: Add readymedia-service-type. Resent-From: Bruno Victal Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Fri, 23 Aug 2024 15:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72398 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Arun Isaac , Fabio Natali Cc: 72398@debbugs.gnu.org Received: via spool by 72398-submit@debbugs.gnu.org id=B72398.172442677414157 (code B ref 72398); Fri, 23 Aug 2024 15:27:01 +0000 Received: (at 72398) by debbugs.gnu.org; 23 Aug 2024 15:26:14 +0000 Received: from localhost ([127.0.0.1]:40011 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1shWB3-0003gH-PJ for submit@debbugs.gnu.org; Fri, 23 Aug 2024 11:26:14 -0400 Received: from smtpm2.myservices.hosting ([185.26.105.233]:39634) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1shWB1-0003g5-Jv for 72398@debbugs.gnu.org; Fri, 23 Aug 2024 11:26:12 -0400 Received: from mail1.netim.hosting (unknown [185.26.106.173]) by smtpm2.myservices.hosting (Postfix) with ESMTP id 74E4420623; Fri, 23 Aug 2024 17:25:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail1.netim.hosting (Postfix) with ESMTP id C95E380095; Fri, 23 Aug 2024 17:25:19 +0200 (CEST) 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 LXWEw1IhVref; Fri, 23 Aug 2024 17:25:19 +0200 (CEST) Received: from [192.168.1.239] (unknown [10.192.1.83]) (Authenticated sender: lumen@makinata.eu) by mail1.netim.hosting (Postfix) with ESMTPSA id 360C480067; Fri, 23 Aug 2024 17:25:19 +0200 (CEST) Message-ID: <709c0681-3e94-48c4-ae57-f06327b7c6c8@makinata.eu> Date: Fri, 23 Aug 2024 16:25:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <87jzglwcqh.fsf@systemreboot.net> <87h6bhicgf.fsf@fabionatali.com> <4fd9b012-4783-4017-b8a3-47485c0cd657@makinata.eu> <878qwoj25q.fsf@fabionatali.com> <87r0agp27q.fsf@systemreboot.net> Content-Language: en-US From: Bruno Victal In-Reply-To: <87r0agp27q.fsf@systemreboot.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: 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-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Queue-Id: CF4AB726AC X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -10.51 X-Spam-Score: -10.51 X-TUID: M1J2jQ/9Le5Q Hi Arun, On 2024-08-23 00:28, Arun Isaac wrote: >=20 >>>> +(define %readymedia-user-account "readymedia") >>>> +(define %readymedia-user-group "readymedia") >>> >>> I think it would be better to expose this in the >>> readymedia-configuration record-type and have it be oriented around >>> user-account and user-group record-types, i.e. >> >> Fixed, although I'm not sure I'm 100% on board with this. >> >> I'm not completely sure but I have the feeling that a configurable >> ReadyMedia user might theoretically weaken the POLA, e.g. if the user >> chose their own user for this service. >> >> Following up on a related conversation we started on IRC, I suppose we= >> should either go all in with flexibility (i.e. allow the user to switc= h >> off the least-authority-wrapper and set the service user) or adopt a >> slightly more rigid approach (mandated POLA and fixed user). >> >> I think I might have a slight preference for the latter, prioritising >> compartmentalisation over flexibility - but I'm keen to know what you,= >> Arun, and all other Guixers may think about this. >=20 > I am with Fabio on this. Many (almost all, maybe?) services use a fixed= > user account that cannot be configured. And, that's ok. Without delving into the quantifying, there's at least a few of them that offer this feature. (in my experience, I've had to rely on this for = a few services already so it's not merely a theoretical concern) Should you ever need to "tweak" a fixed user-account service you're going to end up with something like [1] (beginning from line 21, rationale given at line 39). Not exactly desirable and although the example above pertains to nginx + cgit if I'm not mistaken, a similar situation arises in the following (fictional) setup: /media/NFS/my-media/=E2=80=A6 (owner: foo, group: bigmedia, #= o750) /media/jumbodisk/my-media/=E2=80=A6 (owner: bar, group: bigmedia, #= o750) /media/something-else/library/=E2=80=A6 (owner: baz, group: bigmedia, #= o750) and wholesame chown'ing them to "readymedia" wouldn't make sense/be a good idea (say, each of the directories is under control by a downloader/synchronizing daemon with it's own user-account). > I don't think we should make the least authority wrapper optional > either. Making it optional would be too much complexity for little > benefit. (=E2=80=A6) I don't think so, it amounts to: =E2=80=A2 a boolean field named least-authority-wrapped? in the configura= tion record-type =E2=80=A2 an if statement, e.g. (if least-authority-wrapped? (least-autho= rity-wrapper =E2=80=A6) readymedia) As for the reason of this, consider a setup where the media directories contain symlinks to directories outside of it. It can be infeasible to duplicate the files or "just move them then", in those cases an escape hatch makes sense to be. It's not as secure as the least-authority wrappe= d one but that's a compromise opted in by the user. > (=E2=80=A6) The goal of Guix services isn't to provide total > configurability, but rather to be slightly opinionated so as to nudge > users in the right direction. I'm not against this idea, just pointing out that it's overly rigid right= now and that users with a non "uniform" setup will simply resort to harder to understand manipulations like [1] or wholesale duplicate gnu/services/upnp.scm and tweak it themselves. Let me know if there's anything I missed, [1]: --=20 Cheers, Bruno.