[Toybox] runcon requires CONFIG_TOYBOX_NORECURSE=y

[enh]

On Tue, Jan 19, 2016 at 1:12 PM, Rob Landley <rob at landley.net> wrote:
> On 01/19/2016 12:28 PM, enh wrote:
>> runcon works by saying "when i exec, switch to this context" and then
>> calling exec. unfortunately, xexec is too clever and will avoid
>> actually exec'ing if it recognizes that it would just be a call back
>> into toybox.
>>
>> so "runcon blah /system/bin/id" would work, because toybox would
>> actually exec, but "runcon blah id" wouldn't, because toybox would
>> just toy_exec "id". this was subtle enough to go unnoticed for some
>> time.
>>
>> i've "fixed" it for now by just setting CONFIG_TOYBOX_NORECURSE=y
>> (https://android-review.googlesource.com/#/c/196953/) but i wondered
>> whether we should have a #error or something in runcon.c to make it
>> clear if you're building a broken configuration?
>
> That disables recursing globally. If you want to disable recursing
> locally, set toys.stacktop = 0. (Or just call execvp() yourself, but
> xexec() has error handling code you'd have to duplicate, so...)
>
> I'll commit a fix.

cool, thanks. i'll revert my change when yours is in (don't see it yet).

> Thanks,
>
> Rob
>
> (P.S. In THEORY they may someday be a future exit handling path via the
> longjmp rebound stuff that does things like free toys.optargs, in which
> case incrementing toys.optargs would screw it up. Not a problem here,
> just a general "thing I have in mind to maybe attempt someday". That's
> why I usually snapshot toys.optargs into a temp before looping over it,
> and so on.)

seems like there are several instances in the codebase already (though
at least two of them are mine).

> (P.P.S. I'm sure that kind of cleanup code would make the valgrind
> people happy, but do you know WHY the valgrind people care? Who's
> running valigrind here?

when _i_ say valgrind, i usually mean asan. valgrind's too slow to be
useful, but asan's the kind of thing you can build the whole system
with. it's popular both for specific one-off uses ("i'm tracking down
some app bug") and also more generally for fuzzing.

> A number of commands don't even have _attempts_
> at TOYBOX_FREE exit cleanup code yet.

personally i care a lot less about leaks than i do about reading
uninitialized memory (like the recent ls case).

(interestingly, although Android's debug malloc's leak detection has a
special "give up on mksh, it's hopeless" special case, there isn't one
for toybox. no one's brought that up yet.)

> For example I'm implementing top
> right now and noticing that iotop (which I'm mergeing with it) doesn't
> free its process arrays on exit. If you run run iotop from within a
> bootloader, it would have to. Right now, that's a blue sky todo item,
> but is it important to somebody...? I got a "please prioritize xz
> decompress" email last week, but haven't had anybody ping me about
> bootloaders.

ps/top are the two remaining big-ticket items as far as i'm concerned.
i haven't been saying anything (or sending any patches recently)
because it seems too much "under construction" at the moment. i'm
assuming you'll finish after i can make changes in N but before N
ships, so i'll fix up anything still broken at that time and then
switch us over for O (but still probably before N ships).

> Then again I didn't even know the cyanogenmod guys had
> switched to toybox until I stumbled accross it in an unrelated google
> search, and they've got a whole tree of changes for building on macosx.
> Why? I dunno. Not sure how to ask them...)

they track AOSP, so us switching to toybox switches them. i've no idea
what they're doing with Mac OS though. the AOSP makefile doesn't try
to build toybox for the host. long-term i'd like to stop checking in
the generated files, and that would require me to build at least those
tools on the host, but trying to fit what you do into our build system
seems sufficiently painful that i'll probably never get around to it
unless someone volunteers.

-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.