[Toybox] Some questions re: init...

[ibid.ag at gmail.com]

On Sun, Jan 05, 2014 at 11:49:31AM -0600, Rob Landley wrote:
> On 01/01/14 03:26, ibid.ag at gmail.com wrote:
> >I was looking over init, and noticed some things that seemed possibly
> >less than optimal, as well as one detail that seemed illogical.
> 
> I haven't done any cleanup on this one yet. It could be doing anything...
> 
> >First, the oddity:
> >   p = getenv("TERM");
> >#ifdef VT_OPENQRY
> >   int terminal_no;
> >   if (ioctl(0, VT_OPENQRY, &terminal_no)) {
> >     if (!p || !strcmp(p,"linux")) putenv((char*)"TERM=vt102");
> >   } else
> >#endif
> >   if (!p) putenv((char*)"TERM=linux");
> >
> >As I read it, this code will set TERM to vt102 if
> >(1) the VT_OPENQRY ioctl is supported, AND
> >(2) TERM is not set or is set to "linux".
> 
> Now I'm curious: typecasting a string constant to char * in your
> above quoted snippet is _crazy_, but it's idiosyncratic crazy of a
> kind that's easy to track. I.E. it looks like an easter egg:
> 
> $ grep vt102 busybox/init/init.c
>   putenv((char*)"TERM=vt102");
> 
> And busybox is doing it too. Presumably copied from the same BSD
> source. Neither ever asked "is there a reason to do this?" Sigh.

It's not in any BSD init.
(I've checked for "(char*)" and "vt102" in NetBSD, MirOS, BSDI, 
BSD-lite2, and FreeBSD init.c--neither is there.)

OK...vt102 is supposed to be "if it's a serial line", and busybox had it
from the beginning.
(char*)"string" dates to 06c0a71d23/Jan 27, 2007, and is as preparation
for -Wwrite-strings.
Which is to say, the result of some gcc/GNU insanity.
Judging by the number of times it pops up in pending/, I guess that
Ashwini's team is used to turning that warning on.

> There's more than one reason I isolate new submissions in pending
> until I get a chance to go over it with a magnifying glass...
> 
> By the way, one thing I worry about with submissions is people
> assuming every BSD license version is exactly the same as every
> other BSD license version, especialy since toybox's version is
> unique in not having the "copy this license text into other things"
> viral clause.
> 
> And yes, BSD is viral. People tend to assume that BSD and GPL are
> compatible in the absence of the advertising clause, but BSD's "copy
> this text verbatim into anything that uses even a snippet of it"
> could be viewed as an 'additional restriction' in GPL terms, and
> trying to hide the conflict by copying the BSD license to the _end_
> of the file with the GPL boilerplate up front just makes the problem
> less obvious, it doesn't diminish it. Yes, people do that:
> 
>   http://git.busybox.net/busybox/tree/networking/ping.c
> 

Mentioned before. I suspect the rationale is "The GPL requires you to
keep the GPL/copyright notice, so BSD requiring the BSD/copyright notice
is fine." 
I have doubts about relicensing, though.

> You can't say nobody's been sued for violating a BSD license because
> AT&T vs BSDI was the first big Unix lawsuit. I have no idea _what_
> crazy trolls will try. (Then again the BSDi suit sort of established
> that if you rewrite something enough, eventually none of the
> original code remains. I'd rather not lean too heavily on that,
> though.)
> 
> I'll clean it all out when I get around to rewriting init. Possibly
> from scratch. I try not to do that because it discourages
> contributors, but when it comes to licensing I sleep way better at
> night knowing where the code came from.
> 

> >This ioctl returns 1 to MAX_NR_CONSOLES or -1, so
> >   if (ioctl(0, VT_OPENQRY, ...))
> >will ALWAYS be true since (-1) is still nonzero.
> >But I don't see why "is another tty available" should change the
> >environment of the one tty.
> 
> Do android phones have vga ttys? Do modern systems care much about
> them? Aren't they specified in inittab anyay?
> 
> >I see no point to this oddity, especially given the common use of
> >"TERM=linux".
> >Deleting this would lose the one #ifdef.
> 
> I'm pretty happy just hardwiring in TERM=linux if it's not already
> set. (Although possibly this is the shell's job and not init's? Sad
> there's no spec for init...)

The shell doesn't set TERM; it reads it.
It's the job of "whatever provides a tty", which in this case means init
is on the hook.

> >Second, I note that init.c uses a number of x* functions and calls
> >error_exit() in some cases...
> >These could panic the system on failure.
> 
> Indeed. Although if malloc fails for PID 1 your system's pretty
> hosed to begin with. (Remember, it means you ran out of _virtual_
> address space, or somebody thought it was a good idea to enable
> strict overcommit in which case they get to keep the pieces.)

Which is this case:
> >-x*alloc/xstrdup/xmsprintf (lines 119-121, 153-155, 169) in the inittab
> >parsing is justifable; if malloc fails before init starts anything,
> >there's no way we're running anything.
> >


> >-final_run will panic if fork()/vfork() fails (line 236).
> 
> Yeah, it shouldn't. That can happen because of a forkbomb. The
> traditional init behavior is to just wait it out.
> 
> It's possible init should be able to do something more proactive in
> that case (killall -1 and relaunch daemons if it persists for more
> than 15 seconds maybe), but that's beyond the domain of sysvinit and
> into containers...
> 
> >-Do we need to exit on failure to write informational messages?
> >I'm thinking of lines 55 (failure to open console) and 439 ("started
> >init" message).
> 
> Nope. We inherited a console from somewhere (in the form of pid
> 0-2), if we can't open the new one keep using the old one.

So those two need changing.

Thanks,
Isaac Dunham