From: Christopher Lemmer Webber <cwebber@dustycloud.org>
To: "Gábor Boskovits" <boskovits@gmail.com>
Cc: Guix-devel <guix-devel@gnu.org>,
Maxim Cournoyer <maxim.cournoyer@gmail.com>
Subject: Re: Setuid programs
Date: Thu, 10 Sep 2020 11:01:24 -0400 [thread overview]
Message-ID: <87ft7pznej.fsf@dustycloud.org> (raw)
In-Reply-To: <CAE4v=pjdM29yZszpT57SOkjJPt1t_pnAYNOn80BE1gmAa+sZ0w@mail.gmail.com>
Gábor Boskovits writes:
> Hello,
>
> Christopher Lemmer Webber <cwebber@dustycloud.org> ezt írta (időpont:
> 2020. szept. 10., Cs, 0:52):
>>
>> Christopher Lemmer Webber writes:
>>
>> > Gábor Boskovits writes:
>> >
>> >> Hello,
>> >>
>> >> Christopher Lemmer Webber <cwebber@dustycloud.org> ezt írta (időpont:
>> >> 2020. szept. 9., Sze, 21:00):
>> >>>
>> >>> Maxim Cournoyer writes:
>> >>>
>> >>> > Hello Gabor!
>> >>> >
>> >>> > Gábor Boskovits <boskovits@gmail.com> 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 grained
>> >>> >> 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 that
>> >>> >> 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 using 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 make
>> >>> 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. Let'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 though!
next prev parent reply other threads:[~2020-09-10 15:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-27 6:34 Setuid programs Gábor Boskovits
2020-08-28 4:43 ` Maxim Cournoyer
2020-09-09 19:00 ` Christopher Lemmer Webber
2020-09-09 21:31 ` Gábor Boskovits
2020-09-09 22:19 ` Christopher Lemmer Webber
2020-09-09 22:52 ` Christopher Lemmer Webber
2020-09-10 7:27 ` Gábor Boskovits
2020-09-10 15:01 ` Christopher Lemmer Webber [this message]
2020-09-16 13:25 ` Ludovic Courtès
2020-09-17 0:27 ` Gábor Boskovits
2020-11-07 17:15 ` Christopher Lemmer Webber
2020-11-14 20:18 ` Christopher Lemmer Webber
2020-11-16 17:44 ` Christopher Lemmer Webber
2020-11-16 23:39 ` Christopher Lemmer Webber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ft7pznej.fsf@dustycloud.org \
--to=cwebber@dustycloud.org \
--cc=boskovits@gmail.com \
--cc=guix-devel@gnu.org \
--cc=maxim.cournoyer@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).