3 ms·

Unix domain sockets are the way to pass open file descriptors between processes, though (why? I don't know, it just is). I think that because of that, the mec

by spc476 13y ago

Unix domain sockets are the way to pass open file descriptors between processes, though (why? I don't know, it just is). I think that because of that, the mechanism was extended to also pass along the PID, UID and GID. I did use the open file descriptor with SO_PEERCRED options to implement a Linux-only daemon to open privileged sockets on behalf of a process: https://github.com/spc476/ipacld https://github.com/spc476/ipacld (something I'm surprised has never been written before).

asveikau 13y ago
I think the easier way is to create the socket with high privileges, then drop down to lower privilege.
- 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 ago
    A 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 ago
    Well, 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.)

by spc476 13y ago

asveikau 13y ago

I think the easier way is to create the socket with high privileges, then drop down to lower privilege.

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 ago
  A 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 ago
  Well, 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.)