dev/console catch 22

[Michael Cashwell]

On Tue, 2007-06-19 at 09:52 -0400, Mike Frysinger wrote:

> On Tuesday 19 June 2007, Michael Cashwell wrote:
> > So the file hierarchy served by the NFS server must be written by the a
> > host process and I still have the issue of needing elevated privileges
> > to do that for the special console node.
> 
> i dont really buy this ... only the root user can set up NFS exports and in 
> order for it to be usable by the embedded machine, it has to have root 
> access

I disagree. The NFS setup is only done once per NFS server. So while the
exported space is insecure and it took elevated privileges to create,
it's just developmental scratch space and has no security implication on
other hosts.

>  ... so basically, your system is already insecure so giving away sudo 
> to everyone is exactly the same

I don't know what "system" you are talking about here. The insecure NFS
export is on a machine dedicated to that task. And besides, denying the
developers sudo access was never my goal. (They need it for quite a few
other reasons anyway.) Heck, I'm one of those developers too!

My goal is to avoid habituating the use of sudo in our normal workflow.
The reason is that it's dangerous when something goes wrong. I've
mandated that when cross-compiling there is to be no need for the power
of "sudo make install". That one rule has saved me on several occasions
when something was wrong in the build process and it went off trying to
install into the host's protected areas (/etc, /lib, /bin). A sane
cross-build process that avoids the needless use of elevated privileges
protects against those mishaps.

My goal was to either find a way to create the target console node
without elevated host privileges or to avoid needing the device node in
the first place.

> > The odd part is that all this worked under the 2.4.20 kernel and an
> > earlier version of Busybox. My hunch is that the now-deprecated devfs
> > was handling the console node for me without me even knowing it.
> 
> correct

It's nice to understand what changed.

> > Under 
> > the new sysfs / mdev we must get further into init before the console
> > works. That's all just supposition on my part but it's the largest
> > different from what used to work that I can see.
> 
> not really, /dev is assumed to at least have /dev/console before userspace 
> even starts ... if it doesnt, you're right back where i said and that's 
> patching init to open /dev/console and re-exec itself

Yes, for the strict interpretation of console this seems to be true. But
as noted in a later email it's a small window of lost console output.

> you could also do init=/sbin/pre_init which is a small piece of code that 
> simply creates /dev/console and then opens it up for std{in,out,err} before 
> doing execv(/sbin/init)

I've essentially done this by using a systinit script to create the
device node and then do an askfirst /bin/ash (or /bin/login) to then use
that node to get a shell on the target over the serial port. init never
has a console but I can live with that.

I am left wondering if there isn't some way to get init to actually
reexec itself without patching it. It seems that the inittab restart
would do that if I could get init to exit. But given my inittab success
I have back the main functionality I needed so further exploration will
have to wait.

Thanks for the input.

-Mike