Using CHILD_SUBREAPER in GNU Shepherd

Hi, There is a feature present in Linux: CHILD_SUBREAPER. It changes the logic for reparenting orphaned processes. Instead of an orphaned process being reparented to pid1, an orphaned process is reparented to the nearest parent that is marked as a CHILD_SUBREAPER. A process can mark itself as a

Re: Providing an alternative to setuid in GuixSD

l...@gnu.org (Ludovic Courtès) writes: > I think we must just be clear that GuixSD will be the only one to > benefit from a solution along the lines you wrote, at least for the > foreseeable future. Well, I am slightly more optimistic than that. It may be that this solution is such a success that

Re: Providing an alternative to setuid in GuixSD

Christopher Allan Webber writes: > So, you're running psudo, and this thing maybe accepts connections over > something more secure, *maybe* unix domain sockets... so restrict group > access to the socket to users in the "psudo" group. > > From there, maybe it could require

Re: Providing an alternative to setuid in GuixSD

l...@gnu.org (Ludovic Courtès) writes: > Well, the kernel Linux will forever support setuid binaries That can be selectively turned off per-mount, simply specify the nosuid option. And so eventually we can get to a point where setuid is a Linux build configuration option, which distros can turn

Re: Providing an alternative to setuid in GuixSD

Chris Marusich writes: > Hi, > > I don't think I have all the answers, but this is an interesting topic, > so I'll chime in with what I can. I'm sure others will have more > thoughts to share, too. > > sba...@catern.com writes: > >> 1. Each binary is an attack surface which

Providing an alternative to setuid in GuixSD

Hi guix-devel, Has any effort been put into eliminating the need for setuid binaries from GuixSD? I would be interested in working on that. == Why remove setuid binaries? == setuid binaries are problematic for two reasons: 1. Each binary is an attack surface which is frequently exploited by

Re: Developing libraries for the GNU system with Guix

l...@gnu.org (Ludovic Courtès) writes: > sba...@catern.com skribis: >> - Currently every dependency is located at a well known globally unique >> and globally meaningful path; add some kind of "variant package" >> construct which specifies a package which is "passed in" to the >> environment

Developing libraries for the GNU system with Guix

Hi guix-devel, When I am hacking on some library Z, I continuously want to test the effects that my changes to Z have on packages A/B/C which depend on Z. The same applies, in general, when hacking on any package Z which other packages A/B/C depend on: While developing, I want to be able to

Re: GUIX_LOCPATH in daemon unit file

I think including glibc-utf8-locales in the binary tarball is a good idea, it eases usability and doesn't really have any downsides. (if a really minimal tarball is needed for some purpose, that can be built separately)

Foreign distro GUIX_LOCPATH errors when installing from manual

Hi, I was just getting started with Guix by installing it on my regular distro, Debian Jessie, by following the manual (which is really great - I tried installing Nix first but couldn't get it to work, the Guix manual is much better). The install was successful but I noticed two errors related