guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Setuid programs


From: Christopher Lemmer Webber
Subject: Re: Setuid programs
Date: Wed, 09 Sep 2020 18:52:52 -0400
User-agent: mu4e 1.4.12; emacs 26.3

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.  The current
setuid-programs could be kept as legacy behavior that installs an
additional service.  Thoughts?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]