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? Best regards, g_bor -- OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
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
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?`
(setuid setuid-setuid)
;; Likewise?
(setgid setuid-setgid)
;; Presumably the use we want to set this to
(user setuid-user)
;; Presumably the group we want to se this to
(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?
- Chris
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. > > - Chris Best regards, g_bor -- OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
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.
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?
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
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!
Hi,
Gábor Boskovits <boskovits@gmail.com> skribis:
> 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?
There’s already ‘setuid-program-service-type’. I think the way forward
would be to:
1. Define the <setuid-program> record type you propose.
2. Have ‘setuid-program-service-type’ accept that through its
extensions. When it receives something else, it should
transparently turn it into a <setuid-program> record, for backward
compatibility, and emit a deprecation warning.
3. Document the OS ‘setuid-programs’ field as taking a list of such
records.
How does that sound?
Thanks,
Ludo’.
Hello, Ludovic Courtès <ludo@gnu.org> ezt írta (időpont: 2020. szept. 16., Sze, 15:25): > > Hi, > > Gábor Boskovits <boskovits@gmail.com> skribis: > > > 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? > > There’s already ‘setuid-program-service-type’. I think the way forward > would be to: > > 1. Define the <setuid-program> record type you propose. > > 2. Have ‘setuid-program-service-type’ accept that through its > extensions. When it receives something else, it should > transparently turn it into a <setuid-program> record, for backward > compatibility, and emit a deprecation warning. > > 3. Document the OS ‘setuid-programs’ field as taking a list of such > records. > > How does that sound? Sounds good to me. I will have a look. > > Thanks, > Ludo’. Best regards, g_bor -- OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
Gábor Boskovits writes:
> Hello,
>
> Ludovic Courtès <ludo@gnu.org> ezt írta (időpont: 2020. szept. 16., Sze, 15:25):
>>
>> Hi,
>>
>> Gábor Boskovits <boskovits@gmail.com> skribis:
>>
>> > 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?
>>
>> There’s already ‘setuid-program-service-type’. I think the way forward
>> would be to:
>>
>> 1. Define the <setuid-program> record type you propose.
>>
>> 2. Have ‘setuid-program-service-type’ accept that through its
>> extensions. When it receives something else, it should
>> transparently turn it into a <setuid-program> record, for backward
>> compatibility, and emit a deprecation warning.
>>
>> 3. Document the OS ‘setuid-programs’ field as taking a list of such
>> records.
>>
>> How does that sound?
>
> Sounds good to me. I will have a look.
>
>>
>> Thanks,
>> Ludo’.
>
> Best regards,
> g_bor
Hi! It's been a bit since progress has been made on this, and I wonder
if I can help?
Getting Postfix included in Guix is my last step before moving my main
servers from Debian -> Guix so I'm feeling motivated. ;)
Ludovic Courtès writes:
> Hi,
>
> Gábor Boskovits <boskovits@gmail.com> skribis:
>
>> 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?
>
> There’s already ‘setuid-program-service-type’. I think the way forward
> would be to:
>
> 1. Define the <setuid-program> record type you propose.
>
> 2. Have ‘setuid-program-service-type’ accept that through its
> extensions. When it receives something else, it should
> transparently turn it into a <setuid-program> record, for backward
> compatibility, and emit a deprecation warning.
>
> 3. Document the OS ‘setuid-programs’ field as taking a list of such
> records.
>
> How does that sound?
>
> Thanks,
> Ludo’.
This sounds like a good plan. I'm taking a stab at it, but there's a
good chance I'll get it wrong, so review will be seriously needed.
Let's find out how I do!
[-- Attachment #1: Type: text/plain, Size: 1621 bytes --] Christopher Lemmer Webber writes: > Ludovic Courtès writes: > >> Hi, >> >> Gábor Boskovits <boskovits@gmail.com> skribis: >> >>> 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? >> >> There’s already ‘setuid-program-service-type’. I think the way forward >> would be to: >> >> 1. Define the <setuid-program> record type you propose. >> >> 2. Have ‘setuid-program-service-type’ accept that through its >> extensions. When it receives something else, it should >> transparently turn it into a <setuid-program> record, for backward >> compatibility, and emit a deprecation warning. >> >> 3. Document the OS ‘setuid-programs’ field as taking a list of such >> records. >> >> How does that sound? >> >> Thanks, >> Ludo’. > > This sounds like a good plan. I'm taking a stab at it, but there's a > good chance I'll get it wrong, so review will be seriously needed. > Let's find out how I do! I've attached a patch that includes my plan for the setuid stuff. I could submit this to guix-patches I suppose if that would be better. But I wonder if I should actually just rebase the wip-postfix on top of master, apply this, and then start working on setting up postfix to make use of it. What do you think of this approach? [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-services-setuid-More-specific-setuid-support.patch --] [-- Type: text/x-patch, Size: 7200 bytes --] From cab9f7c017fb2ea0c8dc80084c3c269fa8e85378 Mon Sep 17 00:00:00 2001 From: Christopher Lemmer Webber <cwebber@dustycloud.org> Date: Sun, 15 Nov 2020 16:58:52 -0500 Subject: [PATCH] services: setuid: More specific setuid support. New record <setuid-program> with fields for setting the specific user and group, as well as specifically selecting the setuid and setgid bits, for a program within the setuid-program-service. * gnu/services.scm (<setuid-program>): New record type. (setuid-program, make-setuid-program, setuid-program?) (setuid-program-program, stuid-program-setuid?, setuid-program-setgid?) (setuid-program-user, setuid-program-group): New variables, export them. (setuid-program-entry): New variable, a procedure used for the service-extension of activation-service-type as set up by setuid-program-service-type. Unpacks the <setuid-program> record, handing off within the gexp to activate-setuid-programs. (setuid-program-service-type): Make use of setuid-program-entry. * gnu/build/activation.scm (activate-setuid-programs): Update to expect a ftagged list for each program entry, pre-unpacked from the <setuid-program> record before being handed to this procedure. --- gnu/build/activation.scm | 40 ++++++++++++++++---------------- gnu/services.scm | 49 +++++++++++++++++++++++++++++++++++++--- 2 files changed, 67 insertions(+), 22 deletions(-) diff --git a/gnu/build/activation.scm b/gnu/build/activation.scm index 4b67926e88..a2bdfd5aa5 100644 --- a/gnu/build/activation.scm +++ b/gnu/build/activation.scm @@ -229,13 +229,6 @@ they already exist." (define (activate-setuid-programs programs) "Turn PROGRAMS, a list of file names, into setuid programs stored under %SETUID-DIRECTORY." - (define (make-setuid-program prog) - (let ((target (string-append %setuid-directory - "/" (basename prog)))) - (copy-file prog target) - (chown target 0 0) - (chmod target #o6555))) - (format #t "setting up setuid programs in '~a'...~%" %setuid-directory) (if (file-exists? %setuid-directory) @@ -247,18 +240,27 @@ they already exist." string<?)) (mkdir-p %setuid-directory)) - (for-each (lambda (program) - (catch 'system-error - (lambda () - (make-setuid-program program)) - (lambda args - ;; If we fail to create a setuid program, better keep going - ;; so that we don't leave %SETUID-DIRECTORY empty or - ;; half-populated. This can happen if PROGRAMS contains - ;; incorrect file names: <https://bugs.gnu.org/38800>. - (format (current-error-port) - "warning: failed to make '~a' setuid-root: ~a~%" - program (strerror (system-error-errno args)))))) + (for-each (match-lambda + [('setuid-program src-path setuid? setgid? uid gid) + (catch 'system-error + (lambda () + (let ((target (string-append %setuid-directory + "/" (basename src-path))) + (mode (+ #o0555 ; base permissions + (if setuid? #o4000 0) ; setuid bit + (if setgid? #o2000 0)))) ; setgid bit + (copy-file src-path target) + (chown target uid gid) + (chmod target mode))) + (lambda args + ;; If we fail to create a setuid program, better keep going + ;; so that we don't leave %SETUID-DIRECTORY empty or + ;; half-populated. This can happen if PROGRAMS contains + ;; incorrect file names: <https://bugs.gnu.org/38800>. + (format (current-error-port) + "warning: failed to make '~a' setuid-root: ~a~%" + (setuid-program-program program) + (strerror (system-error-errno args)))))]) programs)) (define (activate-special-files special-files) diff --git a/gnu/services.scm b/gnu/services.scm index 4b30399adc..7e03808489 100644 --- a/gnu/services.scm +++ b/gnu/services.scm @@ -87,6 +87,14 @@ ambiguous-target-service-error-service ambiguous-target-service-error-target-type + setuid-program + setuid-program? + setuid-program-program + setuid-program-setuid? + setuid-program-setgid? + setuid-program-user + setuid-program-group + system-service-type provenance-service-type sexp->system-provenance @@ -773,13 +781,48 @@ directory." FILES must be a list of name/file-like object pairs." (service etc-service-type files)) +(define-record-type* <setuid-program> setuid-program make-setuid-program + setuid-program? + ;; Path to program to link with setuid permissions + (program setuid-program-program) ;string + ;; Whether to set user setuid bit + (setuid? setuid-program-setuid? ;boolean + (default #t)) + ;; Whether to set user setgid bit + (setgid? setuid-program-setgid? ;boolean + (default #t)) + ;; The user this should be set to (defaults to root) + (user setuid-program-user ;integer + (default 0)) + ;; Group we want to set this to (defaults to root) + (group setuid-program-group ;integer + (default 0))) + +(define (setuid-program-entry programs) + #~(activate-setuid-programs + ;; convert into a tagged list structure as expected by + ;; activate-setuid-programs + (list #$@(map (match-lambda + [(? setuid-program? sp) + #~(list 'setuid-program + #$(setuid-program-program sp) + #$(setuid-program-setuid? sp) + #$(setuid-program-setgid? sp) + #$(setuid-program-user sp) + #$(setuid-program-group sp))] + ;; legacy, non-<setuid-program> structure + [program + ;; TODO: Spit out a warning here? + #~(list 'setuid-program + #$program + #t #t 0 0)]) + programs)))) + (define setuid-program-service-type (service-type (name 'setuid-program) (extensions (list (service-extension activation-service-type - (lambda (programs) - #~(activate-setuid-programs - (list #$@programs)))))) + setuid-program-entry))) (compose concatenate) (extend append) (description -- 2.29.1
Christopher Lemmer Webber writes:
> I've attached a patch that includes my plan for the setuid stuff. I
> could submit this to guix-patches I suppose if that would be better.
> But I wonder if I should actually just rebase the wip-postfix on top of
> master, apply this, and then start working on setting up postfix to make
> use of it.
I changed my mind since the setuid stuff is more general, is not blocked
by the postfix work. Thus bug #44700 is tracking this.