This one time, at band camp, Sam Hartman wrote: >Until you get general consensus on a specific goal, I'm unlikely to >accept such changes if they are submitted to me. As a maintainer I >want to be able to look at some statement and answer the following >questions:
Hi Sam, I've just filed the bug with my patch to pam. My goal is not specifically a read-only root (although that may be a useful by-product of it) but just to remove any program state out of /etc. It is my firm belief that programs should not be writing anything to /etc. The patch against pam doesn't ask you to violate the FHS as it currently stands, but it does attempt to test for a file that, if it does exist, violate FHS in its current incarnation. I don't believe that testing for a nonexistent file would warrant a RC-bug, would it? And if the patch against base-files (#191036) and sysvinit (#191041) get accepted, then the changed behaviour of pam wouldn't be a bug against pam. The only FHS violations I am proposing at the moment are to base-files (the creation of /run), sysvinit (using /run/nologin instead of /etc/nologin), and util-linux (#191042, using /run/mtab instead of /etc/mtab). In these cases, violating the FHS is entirely reasonable because we are attempting to improve the FHS. >2) When root is read-only, what information is variable and what information >should be immutable? Why is this a reasonable categorization? IMHO, everything in /etc should be considered immutable by every program, unless the program has been given explicit permission for the current invocation only. That is, any program attempting to modify a file in /etc should first alert the administrator for confirmation. If that cannot be done, then the program shouldn't be writing to /etc. For mount, that means using the correct state directory for mtab, and for sysvinit, that means using the correct state directory for nologin. For the specific case of nologin, which I cover in the patch to sysvinit, shadow, and pam, the admin may create /etc/nologin as they are used to, for this is a configuration file, whereas sysvinit should only create and remove /run/nologin as this is now a program state file. >3) What information needs to go in /var vs /run? As discussed earlier in this thread, /run is only allowed for programs that do not have /var/run available yet. So you see, we are making two changes here: the first is to move state files out of /etc, and the second is to make a directory that mount can use for storing state. -- [EMAIL PROTECTED] http://people.debian.org/~jaq