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

unofficial mirror of guix-devel@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/guix-devel/0 guix-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guix-devel guix-devel/ https://yhetil.org/guix-devel \
		guix-devel@gnu.org
	public-inbox-index guix-devel

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.gnu.guix.devel
	nntp://news.gmane.io/gmane.comp.gnu.guix.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git