From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id qLuoIGPVWV98XQAA0tVLHw (envelope-from ) for ; Thu, 10 Sep 2020 07:27:31 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id iFRcHGPVWV/JWAAAbx9fmQ (envelope-from ) for ; Thu, 10 Sep 2020 07:27:31 +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 4169D94060D for ; Thu, 10 Sep 2020 07:27:31 +0000 (UTC) Received: from localhost ([::1]:44706 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kGGzS-0003Ty-8Z for larch@yhetil.org; Thu, 10 Sep 2020 03:27:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36932) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kGGzK-0003Te-Kx for guix-devel@gnu.org; Thu, 10 Sep 2020 03:27:22 -0400 Received: from mail-ed1-x52f.google.com ([2a00:1450:4864:20::52f]:34558) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kGGzI-00050R-Q5 for guix-devel@gnu.org; Thu, 10 Sep 2020 03:27:22 -0400 Received: by mail-ed1-x52f.google.com with SMTP id q21so5265261edv.1 for ; Thu, 10 Sep 2020 00:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=n6BWVihRjVwK6Yn51zTJIOtyY6RyY7wVNCLn0IbO3B4=; b=TVxjp5mK9wsFhP4txXWjI7Lc+PBatKPw8/vxB/eaNVpNukCr2KPZa2y7GFLCA2+GgQ bamar6NfHDCdFTFyWa0E5+zd3Wl8tFmm1wINvJCH3FgVIqcHMAn/7SO1s4sGfzSYWJLi 6YA5pJ+1MYafuweqzsxOajw5wOARxAuCcbm3170WOdjRI4nc8CJdCY5WOyKf9CQaPRd/ hdm+JujW6mYw2w/3vYBpdoAlC5J7Qa9Dmu4H8ILzrvPPBMpfdJ/MDgOKD/sIumsF4wCm Dfgza545DNu5eLIDkJ25MX7tK7B3MalxxeK0GjKpxb3xMf9TJoqu6TZpuoTySKvpOOh/ ncWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=n6BWVihRjVwK6Yn51zTJIOtyY6RyY7wVNCLn0IbO3B4=; b=JO9MfPXMZIABVCS0umlnMp/M19i/Qmz2733e9qKtXj9/FDmwo/4R2TQZNdDCeCkYAK UW+wLFx/r8l0G2iv7l+27BmQgsbyxmDsFoa3qlBziPLH5tH1SVVAj/Nn50H5lY3h0QK/ T9uyb4Awx69cmIpDwfsWYWc7eZjPF3YL2c4We+ExZBGV2BCH10DDk4IeEPAz6/p88d83 fM+2gHvHO0FPG5ePr8rMYAQDQzN9Cpcikv7vxwPM8pVpC4npi0hgl6WOQEJCF/3ojynp C1xiaRNd/1Gv/apfKN3NM2xQeY1DssLqqhj0uv6ZgFq1EbBtKYfl1VRul8u1S7aAVGt4 TF6g== X-Gm-Message-State: AOAM530In5RrkVOCid+G/UsMTQhFqWrBEgbv/0zx371ezmKwktDD6GPK /RZqgiCXfa2nFuxaLBWlbQ1qCjI6nROh/siy2A== X-Google-Smtp-Source: ABdhPJwDhL0vR7QhM1NBm/m9sNN+UtW4toZsE+tDN83XfVkS9hhtZBrhQSIQAVi85wMI9VlWtkWNk07pEkx8ZIudUHY= X-Received: by 2002:aa7:c693:: with SMTP id n19mr8122245edq.101.1599722839151; Thu, 10 Sep 2020 00:27:19 -0700 (PDT) MIME-Version: 1.0 References: <877dtj753p.fsf@gmail.com> <871rja3hdv.fsf@dustycloud.org> <87eena1tl5.fsf@dustycloud.org> <87wo12zhob.fsf@dustycloud.org> In-Reply-To: <87wo12zhob.fsf@dustycloud.org> From: =?UTF-8?Q?G=C3=A1bor_Boskovits?= Date: Thu, 10 Sep 2020 09:27:08 +0200 Message-ID: Subject: Re: Setuid programs To: Christopher Lemmer Webber Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::52f; envelope-from=boskovits@gmail.com; helo=mail-ed1-x52f.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Guix-devel , Maxim Cournoyer Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=gmail.com header.s=20161025 header.b=TVxjp5mK; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Spam-Score: 0.09 X-TUID: cUCikMVhoS4+ Hello, Christopher Lemmer Webber ezt =C3=ADrta (id=C5=91p= ont: 2020. szept. 10., Cs, 0:52): > > Christopher Lemmer Webber writes: > > > G=C3=A1bor Boskovits writes: > > > >> Hello, > >> > >> Christopher Lemmer Webber ezt =C3=ADrta (id= =C5=91pont: > >> 2020. szept. 9., Sze, 21:00): > >>> > >>> Maxim Cournoyer writes: > >>> > >>> > Hello Gabor! > >>> > > >>> > G=C3=A1bor Boskovits writes: > >>> > > >>> >> Hello guix, > >>> >> > >>> >> I would like to propose an extension to how setuid programs are > >>> >> currently handled. The last time I checked it could only do setuid= and > >>> >> setgid root. Some services, such as postfix need a more fine grain= ed > >>> >> setuid setup. I would propose a record type, such as: > >>> >> (setuid > >>> >> (program setuid-program) > >>> >> (setuid setuid-setuid) > >>> >> (setgid setuid-setgid) > >>> >> (user setuid-user) > >>> >> (group setuid-group)) > >>> >> > >>> >> So that there is more fine grained control. > >>> >> > >>> >> I would also propose to move this to the services framework, so th= at > >>> >> services could extend this field on demand. > >>> >> > >>> >> Wdyt? > >>> > > >>> > This sounds great! I also encountered such limitation and tried to > >>> > fixing it in https://issues.guix.info/41763, with some success (and= an > >>> > unresolved limitation pointed by Chriistopher) but I agree that usi= ng a > >>> > record makes more sense and is more future proof. > >>> > > >>> > Maxim > >>> > >>> I'm eager to use Postfix on Guix (maybe it's me, but I just can't mak= e > >>> sense of the weird DSL that opensmtpd uses) so I guess if that's what= 's > >>> necessary it already makes it a good idea. > >>> > >>> However I don't fully understand the syntax of what you proposed. Le= t's > >>> see if I can guess with a fake entry > >>> > >>> #~(setuid > >>> ;; The program to run, from the shady package > >>> (program (string-append #$shady "/bin/scaryfoo") > >>> ;; Would this be a boolean? If so should it be `setuid?` > >> yes, this should be a bool, studi? looks good to me. > >>> (setuid setuid-setuid) > >>> ;; Likewise? > >>> (setgid setuid-setgid) > >> yes, the same thing applies here. > >>> ;; Presumably the use we want to set this to > >>> (user setuid-user) > >> yes, this should just be the uid of the owner > >>> ;; Presumably the group we want to se this to > >> this should be the gid. > >>> (group setuid-group)) > >>> > >>> ... right? > >>> > >>> I guess this could be done in a backwards compatible way; > >>> %setuid-programs could either evaluate to strings or records, so the > >>> "simpler" version can remain an option? > >> Yes, it can be done this way. Actually I had a bit more general > >> solution in mind, > >> I feel there should be service to install a file from a store to a > >> given place, and with all the access control available, > >> like acl-s, if supported. And then provide the whole setuid thing as a > >> backwards compatibility layer, somehow like you described. > >> For now I guess creating this record type and implementing the > >> extended setuid functionality would be a good first step. > > > > A service seems like a really good idea to me in that it feels the most > > composable with how Guix currently approaches things. > > I feel like this one needs more "Guix maintainer" overview. I agree, this would be nice. The current > setuid-programs could be kept as legacy behavior that installs an > additional service. Thoughts? I believe it should be kept and install an additional service. I have two reasons for that: backwards compatibility is really important, so we should not break it, and I believe this would not be hard to do. On the other hand it would be nice to have a more integrated backend, and move as many things into the services infrastructure as practical, and I think this is a good candidate for that. Wdyt? Best regards, g_bor --=20 OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21