On Thu, 06.10.16 12:33, Ivan Chavero (ichavero@xxxxxxxxxx) wrote: > Setting a umask of 0 means that, by default, any file created by systemd > will be world-readable and -writable. Systemd defines a macro called RUN_WITH_UMASK > which is used to temporarily set a more restrictive umask when systemd needs to create > a file with different permissions. This is backwards. The default umask should be restrictive, > so forgetting to change the umask when creating a file would result in a file that obviously > doesn't work. This is called fail-safe design. Well, for starters umask isn't really usable in non-trivial system service. It's per-process, not per-thread. This means changing it all the time is problematic, since if you want to do it properly, you'd have to add locking around it and make sure that any code touching the umask is nice enough to care and take the lock, too. This one major reason most daemons actually decide to turn off the umask entirely, and just make the last argument of open() or mknod() count as it is. Of course, if your daemon is trivial, and only ever has one thread, then umask is fine, but the world isn't like that. Now, PID 1 in systemd itself is pretty much single-threaded in theory. The thing though is that a number of Linux ioctls are blocking in nature. This means if you want to integrate them into a proper, asynchronous event loop you don't really have any other option than to run them in a thread or subprocess. Hence systemd maintains threads for that after all. I wish we wouldn't have to... (Many of the VT and autofs ioctls are blocking, as two examples). But many of the kernel folks never touched userspace code, and didn't really get the message yet that blocking kernel API are a bad idea in 2016 -- see the new getrandom() syscall for example. Guides such as the original "Linux Daemon Writing" HOWTO also suggest turning off umask -- google for it. (And so does daemon(7) actually, as shipped with systemd) In systemd we generally avoid munging with umask or relying on it for the above reasons. But then there's also the problem that a number of library calls and syscalls don't allow passing the file mode for nodes in the file system that shall be created. Most prominently that is bind() when used for creating AF_UNIX sockets in the file system. Since there's no other way to race-freely ensure the right file modes, in this case we actually *do* mangle the umask, and that's what RUN_WITH_UMASK is for, but only this. Or in other words: in a very simple world, yeah, umask is fine. But the real world is much more complex, and in this real world umask is just broken when applied to system services. The author of that blog story doesn't really know what he is talking of. It would have been a good idea for him to first read up on things before starting to bitch how stupid the systemd devs are. Lennart -- Lennart Poettering, Red Hat _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
