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 gLJuIhFAWl90VAAA0tVLHw (envelope-from ) for ; Thu, 10 Sep 2020 15:02:41 +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 wFdHHhFAWl8vIAAAbx9fmQ (envelope-from ) for ; Thu, 10 Sep 2020 15:02:41 +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 089589401CF for ; Thu, 10 Sep 2020 15:02:40 +0000 (UTC) Received: from localhost ([::1]:54614 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kGO5v-0006sm-Uu for larch@yhetil.org; Thu, 10 Sep 2020 11:02:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34170) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kGO4r-0006X7-Kh for guix-devel@gnu.org; Thu, 10 Sep 2020 11:01:33 -0400 Received: from dustycloud.org ([2600:3c02::f03c:91ff:feae:cb51]:41430) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kGO4p-00047I-9c for guix-devel@gnu.org; Thu, 10 Sep 2020 11:01:33 -0400 Received: from twig (localhost [127.0.0.1]) by dustycloud.org (Postfix) with ESMTPS id 3D310266C1; Thu, 10 Sep 2020 11:01:29 -0400 (EDT) References: <877dtj753p.fsf@gmail.com> <871rja3hdv.fsf@dustycloud.org> <87eena1tl5.fsf@dustycloud.org> <87wo12zhob.fsf@dustycloud.org> User-agent: mu4e 1.4.12; emacs 26.3 From: Christopher Lemmer Webber To: =?utf-8?Q?G=C3=A1bor?= Boskovits Subject: Re: Setuid programs In-reply-to: Date: Thu, 10 Sep 2020 11:01:24 -0400 Message-ID: <87ft7pznej.fsf@dustycloud.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2600:3c02::f03c:91ff:feae:cb51; envelope-from=cwebber@dustycloud.org; helo=dustycloud.org X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-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=none; dmarc=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.49 X-TUID: D5R21ls2efjs G=C3=A1bor Boskovits writes: > Hello, > > Christopher Lemmer Webber ezt =C3=ADrta (id=C5= =91pont: > 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 setui= d and >> >>> >> setgid root. Some services, such as postfix need a more fine grai= ned >> >>> >> 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 t= hat >> >>> >> 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 (an= d an >> >>> > unresolved limitation pointed by Chriistopher) but I agree that us= ing 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 ma= ke >> >>> sense of the weird DSL that opensmtpd uses) so I guess if that's wha= t's >> >>> necessary it already makes it a good idea. >> >>> >> >>> However I don't fully understand the syntax of what you proposed. L= et'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 That's fine by me. I don't feel like I'm the right one to make the call th= ough!