4 ms·
But why have the keys to the entire kingdom when all you need is a single key to a single room? The daemon I wrote is very small, so there isn't much code to a
by spc476 13y ago
But why have the keys to the entire kingdom when all you need is a single key to a single room?
The daemon I wrote is very small, so there isn't much code to audit. The client that calls the daemon doesn't need to be root at all. The daemon can also make a lot of different checks (right UID, right GID, right executable image, etc.) before passing the privileged port back to the client.
Edit: fixing the last sentence.
- FooBarWidget 13y agoA lot of stuff is built on the "worse is better" philosophy. Introducing a daemon like yours will complicate the OS a little bit more. So instead, OS developers outsource the complexity to the apps, and only implement a quick hack to make this possible. In practice, the running-as-root-then-drop-privilege pattern works well enough so nobody bothered making a more complex, but potentially more secure, solution.
- asveikau 13y agoWell, you could probably set up a sudoers file that allowed launching your daemon but blocked everything else. A hacky solution, but it does not involve giving up all the keys. I seem to recall reading ages ago how Hurd was going to solve issues like this, and make privileges into something else, tweakable by restarting some user mode process. But I guess there may be something to the other reply about "worse is better" - workable with some hacks is better than ideological purity and non working. (Not to say your daemon doesn't work, I am angling more towards a kernel that doesn't have that arbitrary low-port check.)