[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?