Hey--

I was thumbing through old problem reports and I came across 7170, which
states:

>One of my biggest pet peeves about init is that it requires /dev/console
>to exist in order to do anything useful on the system.  This is both a
>security and flexibility bug.

>There is absolutely no reason that /dev/console should be required for
>single user mode; a possibly corrupt / could (and in my case, has in the
>past!) lose the node, making the sysadmin boot from alternative media in
>order to get the system up and running.

I was thinking about ways to fix this without major kludges (e.g. fixing
up a file descriptor in the kernel before init is exec'd).  I have a
proposal which might be useful in other operating situations.

I was wondering what people think of either adding a special fsid_t
to fhopen() et al or a new system call to create a fd entry for a given
major/minor/type set.  This would allow a few things which aren't possible
now, namely

  - Systems with broken / filesystems would have a much greater chance of
    making it to single-user mode.
  - Embedded systems with no filesystem at all would be easier to create.
  - Moving /dev to a memory-resident filesystem on NFS-rooted boxes will
    become possible.

There are some security considerations--  I propose that the system call
would require that the caller have uid 0 credentials and a view of the
"real" root (e.g. is not in a chroot'd cage).  If there's problems with
this, we could choose to restrict use of the call to pid 1 only, but
that does reduce its utility somewhat for the latter two cases.

I'm willing to try my hand at implementing this if this passes design
review..

Any comments?

Mike