Re: ifupdown writes to /etc... a bug?

[Jamie Wilkinson <jaq@debian.org>]

I see the following reasons why people want a /run:

- Premise 1.  People have a big problem with keeping state in /etc, which is
  considered admin-only territory, mere programs do not have the right to harm
  the sanctity of /etc.

- Premise 2.  People want a "single" location they can mount rw when they have
  a ro root, that early-starup state keeping programs can write to (where
  "early-startup" refers to the fact that these programs are special cases,
  they run before the system is fully operational). 

Some points against the creation of /run that have been brought up, and a
rebuttal against those points:

- /var/run already exists.

  While true, early-startup programs are special cases in the running of the
  system, they may want to write state before /var is mounted.  

- Too much work to implement.

  I think there are two parts to this:

  - Making programs use /run instead of /etc is hard.

    Actually, all we need to do is create /run in some essential package,
    base-files seems the obvious choice.  Then mount and the other
    early-startup programs that need to write state get patched as follows
    (shell pseudocode):
    
      if [ -d /run ]; then
        statefile=/run/mtab
      else
        statefile=/etc/mtab
      fi
    
    This project successfully moved from /usr/doc to /usr/share/doc, I don't
    believe this is any more complicated.
    
  - Making sure /run is writable on all Debian installations is hard.

    That's why we don't try to manage what sort of filesystem is used.  A
    default Debian installation has a rw root.  We can create a /run on the
    same partition as / and it's guaranteed to be on a writable filesystem.
    If admins want to mount root ro and move /run to another filesystem,
    then they are free to do so themselves.
  
- It's against FHS!

  Of course it is, but these programs are already violating FHS by writing
  to locations that they aren't allowed to.  In that case, we can overrule
  the FHS if we believe we are improving the state of the filesystem.

- Keeping track of state files in two locations is more complex than if they
  were in only one location.

  Unix has had a search path for a long time now.  I also don't see why a
  program would have to use *both* locations, they only need to use one of
  them.  Programs should want to write to /var/run before /run, of course --
  it would be considered an improper use of /run for a general system program
  that runs after the system has been initialised to be using /run when
  /var/run is available.
  
- There isn't actually a problem, premise 1 isn't true and premise 2 is not
  Debian's problem, as ro root is a local change to the system and thus we
  don't need to worry about it.

  Well, I have no rebuttal to that.  Certainly premise 2 is no longer our
  problem if we can't accept premise 1, but I invite anyone who actually
  believes that to be the case to come forth and explain their reasoning.

So, I propose the following course of action:

1) Create /run in base-files, mode 755, owned by root.root.
2) Patch those programs using /etc to store state to check for the existence
   of first /var/run and then /run, and use the first found location as the
   location of their state files.  Thus we can use /var/run if (e.g. on a
   workstation) /var has been mounted, and /run if it has not.
3) Amend policy to acknowledge /run and specify that programs requiring a
   location to write state to when the system is still being initialised
   (i.e just after the system has booted, prior to /var being mounted) use
   /run; for all other programs the FHS applies.

Comments?

-- 
jaq@debian.org                               http://people.debian.org/~jaq