On Tue, 11 Aug 2009 10:25:00 -0700 (PDT) Jac Goudsmit <jac_gouds...@yahoo.com> wrote:
> On the other hand, I would say the preinit should be very small and > self-contained, to minimize the chance of bugs or security problems. > After all a simple mistake can brick a device at preinit time. As far > as I understand, preinit should provide fail-safe/fallback > mechanisms, and I wonder if your system (which iterates files > in /etc/preinit.d/conf.d and other locations) might invite problems. > I can easily imagine users bricking their devices by adding, deleting > or changing files in unexpected ways, and I see opportunities for > evildoers to "plug in" malicious software, and that would be bad at > preinit time because when something is wrong with your system, you'll > want a preinit to behave in a perfectly predictable way to bring the > system back to working order. If you use a squashfs the preinit is pluggable only at firmware build time. Anything not on the squashfs doesn't affect preinit, because preinit runs before the rootfs is mounted. The object is not to make the system configurable, but to make it configurable by the firmware builder (e.g. a vendor, VAR, or service provider who wants to use OpenWRT, as is the case of the project I'm working on). For a jffs2 filesystem (e.g. not squashfs) the preinit is modifiable anyway, so I don't see it as any more dangerous. > It would be better to store all the settings in one file, perhaps > hard-code them at the top of the script at build time, and maybe (for > targets that support this) allow a removable device like a USB stick > to hold override settings. That way, even though the configuration > can be changed at runtime (by plugging in a USB stick or whatever), > it's always possible to revert to the flash settings by unplugging it. Not to worry, the preinit always uses the flash settings. > I also wonder how much extra space a modularized preinit might use up > on small devices. Maybe there should be a "master switch" in the > configuration between Ye Olde non-modular preinit, or the New Shiny > preinit stuff? It shouldn't make a noticable difference because it's a squashfs. > So... my vote is "Yes" on the configurable preinit, but a firm "Hmmm > maybe not" on modularizing it. > > Feel free to flame back if this doesn't make sense -- I'm still a > beginner with OpenWRT and as I said I only glanced at your code so I > may be totally off on some (or all?) of my arguments. Heh. I appreciate the feedback. I will also be posting an example of a package that takes advantage of the modular system to extend failsafe to autorestore settings and firmware from a server when failsafe mode is entered (while keeping the option to truly drop to failsafe if need be). So, do you feel better about it knowing that it is only the firmware builder who modifies the behaviour of preinit/failsafe? Regards, Daniel -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://www.bmts.com/~cshore
signature.asc
Description: PGP signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
