Bug 217924
| Summary: | dhclient: Fails to fork into the background with kern.trap_enotcap=1 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Tobias Kortkamp <tobik> | ||||
| Component: | bin | Assignee: | freebsd-bugs (Nobody) <bugs> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | CC: | cem, emaste | ||||
| Priority: | --- | Keywords: | patch | ||||
| Version: | CURRENT | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
Patch was committed in base r325741 |
Created attachment 180966 [details] dhclient.diff With the sysctl kern.trap_enotcap=1, dhclient fails to fork into the background and dies. truss excerpt: 4933: <new process> 4933: setsid() = 4933 (0x1345) 4933: sigaction(SIGHUP,{ SIG_DFL 0x0 ss_t },0x0) = 0 (0x0) 4933: open("/dev/null",O_RDWR,00) ERR#94 'Not permitted in capability mode' 4933: SIGNAL 5 (SIGTRAP) There is an older comment in dhclient.c that says that it is expected that daemon(3) will fail to open /dev/null in a chroot. The is doubly true when in capability mode. dhclient replicates the behavior of daemon(3) in dup'ing /dev/null (with a previously opened fd) anyway, so why isn't noclose set too? This way the attempt to open /dev/null again can be avoided.