On Fri, 20 Apr 2001, Michael Lyle wrote:

> 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

Hmmm... Personally I don't like it. :-) My main objections are: 1) you're
abusing fhopen - file handle innards are supposed to be opaque. Yes, if we
define a special fsid which behaves a certain way, then we've defined
where to put the major, the minor, and the type fields. But it's giving
the idea it's safe to hand-craft file handles, which is not a good
impression to leave.

2) If you define a new fsid, then you've defined a new mount point (since
that's what fsid's number). Maybe your proposal didn't mention everything
you had in mind, but the clean thing to do would be to make a "real" mount
point (it doesn't have to actually appear in the file hierarchy) to handle
this. Hmmm... I'm not sure how to make it not show up when you run
"mount".

>   - 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.

?? While I see how not needing /dev/console will help, the kernel still
wants to mount a file system as root. And it wants to run init off of one.

>   - 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.

If you're doing anything pseudo-filehandle-ish, then you need to be
root. Restricting it to pid 1, though, won't work. The place where init
tries to look up /dev/console, it has already forked. So it's not pid 1
any more.

If the goal is to fix the problem, I think a cleaner fix is to:

1) Have the kernel pass in an open file descriptor on say fd 1 which
is hooked to the console device. fd 1 and fd 2 weould be fine too.

2) in init.c:setctty(), if the revoke failes, we assume that /dev/console
doesn't exist. We then do a login_tty on fd(0). Otherwise we do what we do
now.

Take care,

Bill