5 ms·

> So another, privileged process does the open on its behalf and sends the resulting file descriptor to the primary process for processing. I must be misunders

> So another, privileged process does the open on its behalf and sends the resulting file descriptor to the primary process for processing. I must be misunderstanding something. I assume that the unprivileged process still cannot actually read the file, otherwise you could access unauthorized open files by going through every possible file descriptor. What processing can the unprivileged process do? Keep track processes that have open files?

evmar 13y ago
File descriptors are local to a process (after all, fd 0 is each process's personal stdin). The special extra data passed to sendmsg makes the kernel map a new fd in the receiving process, granting it access to the underlying file. It might help to consider that the fds in the two processes are likely not the same number.
nkurz 13y ago
The only part you might be missing is that the 'send_fd' command needs to be executed by a cooperating privileged process that 'serves' the fd to the receiver. Since the permission checks are done at the time the fd is opened (and not repeated[1]) the receiving process has the full privileges that the sender had: read, write, truncate, etc. Receiving the fd via this mechanism is very different that just getting the number of the fd. Nothing is really passed over the socket, rather behind the scenes the kernel is remapping memory within the calling process. It's very similar to what happens when a process 'forks' and its file descriptors are duplicated, but with individual fd granularity. [1] There are exceptions to this in certain device handlers that use file interfaces, but it holds for regular files.
- archgoon 13y ago
  Thank you (and others). I feel silly for not checking the man pages for the macros I didn't recognize.
noselasd 13y ago
Permission checks are done when you open[1] a file, not when you otherwise operate on it. So yes, you could access "unauthorized" files. It's up to the sending process whether it wants to share particular filedescriptor to someone else, so you can't gain access to something you're not supposed to though. [1] I'm not sure about security frameworks, it may be e.g. SELinux provides more granular checks.

evmar 13y ago

File descriptors are local to a process (after all, fd 0 is each process's personal stdin). The special extra data passed to sendmsg makes the kernel map a new fd in the receiving process, granting it access to the underlying file. It might help to consider that the fds in the two processes are likely not the same number.

nkurz 13y ago

The only part you might be missing is that the 'send_fd' command needs to be executed by a cooperating privileged process that 'serves' the fd to the receiver. Since the permission checks are done at the time the fd is opened (and not repeated[1]) the receiving process has the full privileges that the sender had: read, write, truncate, etc. Receiving the fd via this mechanism is very different that just getting the number of the fd. Nothing is really passed over the socket, rather behind the scenes the kernel is remapping memory within the calling process. It's very similar to what happens when a process 'forks' and its file descriptors are duplicated, but with individual fd granularity. [1] There are exceptions to this in certain device handlers that use file interfaces, but it holds for regular files.

archgoon 13y ago
Thank you (and others). I feel silly for not checking the man pages for the macros I didn't recognize.

noselasd 13y ago

Permission checks are done when you open[1] a file, not when you otherwise operate on it. So yes, you could access "unauthorized" files. It's up to the sending process whether it wants to share particular filedescriptor to someone else, so you can't gain access to something you're not supposed to though. [1] I'm not sure about security frameworks, it may be e.g. SELinux provides more granular checks.