Introduce alternative interface for daemon(3).
This interface allows us to provide an descriptors instead of secretly opening some.
Details
Details
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
It looks like daemon()'s chdir and close actions are performed just before returning successfully; therefore, capability mode code could also call daemon(1, 1) and perform the chdir and/or close actions after it, either open-coded or calling new function(s).
Also, I don't really like the daemon() API since it makes it hard to report startup failures (note, for example, that a kqueue must be created in the process that will use it; it will not work properly in a child process), but we have various applications using it. Anyway...
| lib/libc/gen/daemon.3 | ||
|---|---|---|
| 75 ↗ | (On Diff #36430) | is equal to |
| 77 ↗ | (On Diff #36430) | the current working directory is not changed |
| lib/libc/gen/daemon.c | ||
| 86 ↗ | (On Diff #36430) | Hmm, does the current directory mean anything in a capability mode process? Perhaps this chdir should be moved somewhere else? |
| 107 ↗ | (On Diff #36430) | Unlike before, this will not work if there are no permissions to read /. POSIX defines an O_SEARCH for this; although we do not define this constant, O_EXEC will serve in its place to open a directory while checking x and not r permissions. |
| lib/libc/gen/daemon.c | ||
|---|---|---|
| 86 ↗ | (On Diff #36430) | Yea it doesn't, my goal was to introduce API that can be used outside Capsicum as well. |
Comment Actions
This looks good to me.
BTW, I like the explicit fds. With CheriBSD I've got a part of a prototype of a new API where we have unforgeable capabilities in place of file descriptors so there can be mutual distrust within parts of a process (this is quite disruptive as you'd expect). Avoiding APIs which use fds implicitly will help with migration to such a system if I ever try to take it further.