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; 10+ 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] 10+ 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; 10+ 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] 10+ 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; 10+ 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] 10+ 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; 10+ 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] 10+ 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; 10+ 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] 10+ 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; 10+ 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] 10+ 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; 10+ 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] 10+ 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; 10+ 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] 10+ 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
  1 sibling, 1 reply; 10+ 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] 10+ messages in thread

* Re: Setuid programs
  2020-09-16 13:25             ` Ludovic Courtès
@ 2020-09-17  0:27               ` Gábor Boskovits
  0 siblings, 0 replies; 10+ 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] 10+ messages in thread

end of thread, other threads:[~2020-09-17  0:28 UTC | newest]

Thread overview: 10+ 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

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