* 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).