unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
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


  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).