On Fri, 2021-01-29 at 14:33 +0100, Maxime Devos wrote: > Hi Guix, > [...] > > Below is a summary of their messages, including a mitigation proposal. > > Your feedback is requested! > > I'm writing a patch right now. It's a little more elaborate than my > mkdir-p/own proposal. In the patch, directories with owner, group > and permission bits are created via extensions to a ‘fs-entry-service-type’, > which will perform various basic consistency checks at build time > (e.g., no directory can be owned by multiple users). > > I'll post a draft when it's ready. [First draft is attached, with many parts missing, it doesn't even compile] I think I've got a basic idea on how to handle this. Some problems to address: * Guile does not have ‘openat, mkdirat’ procedures. How to resolve: implement these upstream, write FFI bindings, or use 'chdir' carefully. * Verify whether symlinks are handled correctly. (stat vs lstat vs fstatat ...) * Perhaps O_NOCTTY, O_NOLINK, O_NOTRANS, O_NONBLOCK, O_DIRECTORY, O_NOFOLLOW ... need to be used at some places. * Maybe fsync needs to be used in some places. The service definitions don't seem to do that anywhere when chmodding and chowning, so not implementing this shouldn't be a regression, but it does seem like something to verify. * On some Linux versions and filesystems, the use of O_TMPFILE might simplify reasoning about security properties, race windows, etc., but idk if it's supported on the Hurd, and which (linux version, filesystem) combinations are supported. * Mounting filesystems. Can all filesystems used by services when activating be assumed to be up? idk. * Support more security stuff (SELinux, SMACK, POSIX ACL, ...) Something for the far future, perhaps? Perhaps I should just implement the basic mkdir-p/own proposal for now, and in the future something more elaborate can be implemented? All but the last two points probably still apply, though. I'll take a look at how other systems handle this. Maxime