Hello, Christopher Lemmer Webber <cweb...@dustycloud.org> ezt írta (időpont: 2020. szept. 10., Cs, 0:52): > > Christopher Lemmer Webber writes: > > > Gábor Boskovits writes: > > > >> Hello, > >> > >> Christopher Lemmer Webber <cweb...@dustycloud.org> ezt írta (időpont: > >> 2020. szept. 9., Sze, 21:00): > >>> > >>> Maxim Cournoyer writes: > >>> > >>> > Hello Gabor! > >>> > > >>> > Gábor Boskovits <boskov...@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
