From: "Gábor Boskovits" <boskovits@gmail.com>
To: Christopher Lemmer Webber <cwebber@dustycloud.org>
Cc: Guix-devel <guix-devel@gnu.org>,
Maxim Cournoyer <maxim.cournoyer@gmail.com>
Subject: Re: Setuid programs
Date: Thu, 10 Sep 2020 09:27:08 +0200 [thread overview]
Message-ID: <CAE4v=pjdM29yZszpT57SOkjJPt1t_pnAYNOn80BE1gmAa+sZ0w@mail.gmail.com> (raw)
In-Reply-To: <87wo12zhob.fsf@dustycloud.org>
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
--
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
next prev parent reply other threads:[~2020-09-10 7:27 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 [this message]
2020-09-10 15:01 ` Christopher Lemmer Webber
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='CAE4v=pjdM29yZszpT57SOkjJPt1t_pnAYNOn80BE1gmAa+sZ0w@mail.gmail.com' \
--to=boskovits@gmail.com \
--cc=cwebber@dustycloud.org \
--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).