Hi folks. I recently had a case which made me looking into this and Carsten Hey pointed me to that specific bug report here. Has there been any progress on this? I mean we already use LSB init script headers for dependency based booting... Many scripts already have the status action (and then follow the exit codes as implied by LSB). In my opinion it would make sense, to quite closely follow http://refspecs.freestandards.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html in Debian. One conflict is IIRC, that some exit status which would be reserved by LSB is currently used by some scripts to denote a warning state. Andrew mentioned this problem: >Note that the LSB exit codes are directly in conflict with our own - >they require the init script _fail_ if the program is removed but not >purged, while we require it silently do nothing and return >success. This proposal would therefore introduce bugs in most existing >init scripts. But I guess there are valid use cases in which it's very important that we allow such scripts to fail then. My example: Imagine having a dm-crypt secured system (or perhaps just one device or so). Imagine that a device is decrypted (a mapping is set up) and then cryptsetup is removed (but not purged). It's IMO not possible that cryptsetup simply closes all open dm-crypt devices in it's prerm; if the device is still used (e.g. mounted) closing would fail. Now the initscript remains, most other files from cryptsetup are removed and therefore the initscript is non-functional. From a (meta)security point of view, it must be guaranteed, that if a user says e.g. cryptdisks stop... either the dm-crypt devices are cleanly stopped or he gets a warning and the script fails. If we'd simply exit 0 the user would not notice, that the device is still open, which is a potential security risk. Guess that example pretty well shows why the exit 5 thingy could be actually quite reasonable and (from a security point of view) necessary. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature