Make it possible for init to execute any executable, not just
sh(1) scripts. This means you can now eg rewrite your /etc/rc
in Python.
Details
Details
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| sbin/init/init.c | ||
|---|---|---|
| 1096 ↗ | (On Diff #46179) | This is too rude. Check for exec permissions on the script before trying execv. This should nicely work with /etc/rc which does not have +x. |
| sbin/init/init.c | ||
|---|---|---|
| 1096 ↗ | (On Diff #46179) | But it works just fine with /etc/rc without -x (which seems to be the default). Why check for +x if the execv() will to that anyways? |
| sbin/init/init.c | ||
|---|---|---|
| 1096 ↗ | (On Diff #46179) | What I want is that for normal /etc/rc it was not even tried to pass to execv(e) at all. In other words, I want that the change does not change anything for the current configuration, except for an additional innocent access(2) syscall. |
| sbin/init/init.c | ||
|---|---|---|
| 1096 ↗ | (On Diff #46179) | Okay, but why? What's the scenario where it would improve things? |
| sbin/init/init.c | ||
|---|---|---|
| 1096 ↗ | (On Diff #46179) | execve(2) is complicated syscall which is also hooked by mac modules. You simply do not want to knowingly aggravate all that stack when you can avoid this. |
| sbin/init/init.c | ||
|---|---|---|
| 1096 ↗ | (On Diff #46179) | Sorry, I just don't get it. I can't see a scenario where execve(2) would do "something weird" instead of returning EACCES, apart from having a seriously hosed kernel. Adding an additional pointless check only complicates the (notoriously hard to debug) code. Also, checking for a permission before calling something is an antipattern. |
| sbin/init/init.c | ||
|---|---|---|
| 1096 ↗ | (On Diff #46179) | Execve has pluggable image activators, and pluggable mac framework modules. What they do, and should what they do considered to be 'hosed' highly depends on the circumstances. E.g. if some image activator wrongly claims the binary as its own, while a mac module tries to find a signature and panic kernel when it can etc., should be considered hosed, or we should try to minimally start the system to allow recovery ? The check for 'x' there is a simple matter to detect the executable format (shell script running from the interpreter vs directly activating it). Let me reformulate: I want that there be no change in the syscalls issued by init for the default setup with our /etc/rc. I can tolerate additional access(2), but I do not want execve(2) which could do a lot of strange things which is impossible to diagnose at this early stage. |
Comment Actions
Add the extra access(2) checks, as suggested by kib@, and also
apply the same change to the code that runs /etc/rc.shutdown.
| sbin/init/init.c | ||
|---|---|---|
| 1096 ↗ | (On Diff #46179) | Makes sense, thanks. Okay, I've added the access(2) checks (with extra cautious error reporting, just in case), and extended this to also handle rc.shutdown. This isn't fully tested yet, I'll do that before committing. What do you think? Btw, there's some code duplication. I'll address this in a followup review. |