* Setuid programs
@ 2020-08-27 6:34 Gábor Boskovits
2020-08-28 4:43 ` Maxim Cournoyer
0 siblings, 1 reply; 14+ messages in thread
From: Gábor Boskovits @ 2020-08-27 6:34 UTC (permalink / raw)
To: Guix-devel
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Setuid programs
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
0 siblings, 1 reply; 14+ messages in thread
From: Maxim Cournoyer @ 2020-08-28 4:43 UTC (permalink / raw)
To: Gábor Boskovits; +Cc: Guix-devel
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Setuid programs
2020-08-28 4:43 ` Maxim Cournoyer
@ 2020-09-09 19:00 ` Christopher Lemmer Webber
2020-09-09 21:31 ` Gábor Boskovits
0 siblings, 1 reply; 14+ messages in thread
From: Christopher Lemmer Webber @ 2020-09-09 19:00 UTC (permalink / raw)
To: Maxim Cournoyer; +Cc: guix-devel
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Setuid programs
2020-09-09 19:00 ` Christopher Lemmer Webber
@ 2020-09-09 21:31 ` Gábor Boskovits
2020-09-09 22:19 ` Christopher Lemmer Webber
0 siblings, 1 reply; 14+ messages in thread
From: Gábor Boskovits @ 2020-09-09 21:31 UTC (permalink / raw)
To: Christopher Lemmer Webber; +Cc: Guix-devel, Maxim Cournoyer
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Setuid programs
2020-09-09 21:31 ` Gábor Boskovits
@ 2020-09-09 22:19 ` Christopher Lemmer Webber
2020-09-09 22:52 ` Christopher Lemmer Webber
0 siblings, 1 reply; 14+ messages in thread
From: Christopher Lemmer Webber @ 2020-09-09 22:19 UTC (permalink / raw)
To: Gábor Boskovits; +Cc: Guix-devel, Maxim Cournoyer
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Setuid programs
2020-09-09 22:19 ` Christopher Lemmer Webber
@ 2020-09-09 22:52 ` Christopher Lemmer Webber
2020-09-10 7:27 ` Gábor Boskovits
0 siblings, 1 reply; 14+ messages in thread
From: Christopher Lemmer Webber @ 2020-09-09 22:52 UTC (permalink / raw)
Cc: guix-devel, Maxim Cournoyer
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?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Setuid programs
2020-09-09 22:52 ` Christopher Lemmer Webber
@ 2020-09-10 7:27 ` Gábor Boskovits
2020-09-10 15:01 ` Christopher Lemmer Webber
2020-09-16 13:25 ` Ludovic Courtès
0 siblings, 2 replies; 14+ messages in thread
From: Gábor Boskovits @ 2020-09-10 7:27 UTC (permalink / raw)
To: Christopher Lemmer Webber; +Cc: Guix-devel, Maxim Cournoyer
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Setuid programs
2020-09-10 7:27 ` Gábor Boskovits
@ 2020-09-10 15:01 ` Christopher Lemmer Webber
2020-09-16 13:25 ` Ludovic Courtès
1 sibling, 0 replies; 14+ messages in thread
From: Christopher Lemmer Webber @ 2020-09-10 15:01 UTC (permalink / raw)
To: Gábor Boskovits; +Cc: Guix-devel, Maxim Cournoyer
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!
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Setuid programs
2020-09-10 7:27 ` Gábor Boskovits
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-14 20:18 ` Christopher Lemmer Webber
1 sibling, 2 replies; 14+ messages in thread
From: Ludovic Courtès @ 2020-09-16 13:25 UTC (permalink / raw)
To: Gábor Boskovits; +Cc: Guix-devel, Maxim Cournoyer
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’.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Setuid programs
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
1 sibling, 1 reply; 14+ messages in thread
From: Gábor Boskovits @ 2020-09-17 0:27 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Guix-devel, Maxim Cournoyer
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Setuid programs
2020-09-17 0:27 ` Gábor Boskovits
@ 2020-11-07 17:15 ` Christopher Lemmer Webber
0 siblings, 0 replies; 14+ messages in thread
From: Christopher Lemmer Webber @ 2020-11-07 17:15 UTC (permalink / raw)
To: Gábor Boskovits; +Cc: Guix-devel, Maxim Cournoyer
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. ;)
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Setuid programs
2020-09-16 13:25 ` Ludovic Courtès
2020-09-17 0:27 ` Gábor Boskovits
@ 2020-11-14 20:18 ` Christopher Lemmer Webber
2020-11-16 17:44 ` Christopher Lemmer Webber
1 sibling, 1 reply; 14+ messages in thread
From: Christopher Lemmer Webber @ 2020-11-14 20:18 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Guix-devel, Maxim Cournoyer
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!
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Setuid programs
2020-11-14 20:18 ` Christopher Lemmer Webber
@ 2020-11-16 17:44 ` Christopher Lemmer Webber
2020-11-16 23:39 ` Christopher Lemmer Webber
0 siblings, 1 reply; 14+ messages in thread
From: Christopher Lemmer Webber @ 2020-11-16 17:44 UTC (permalink / raw)
Cc: guix-devel, Maxim Cournoyer
[-- 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
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: Setuid programs
2020-11-16 17:44 ` Christopher Lemmer Webber
@ 2020-11-16 23:39 ` Christopher Lemmer Webber
0 siblings, 0 replies; 14+ messages in thread
From: Christopher Lemmer Webber @ 2020-11-16 23:39 UTC (permalink / raw)
Cc: guix-devel, Maxim Cournoyer
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-11-16 23:41 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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
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).