[Toybox] mknod: -m not working without MKNOD_Z

[Rob Landley]

On 3/21/19 2:53 PM, enh wrote:
> On Thu, Mar 21, 2019 at 11:40 AM Rob Landley <rob at landley.net> wrote:
>>
>> On 3/21/19 10:16 AM, enh via Toybox wrote:
>>> i did notice the other day that not all of the security context stuff
>>> is compiled out, only some of it. is it actually worth the trouble of
>>> compiling it out?
>>
>> When I started toybox I'd just left busybox, and micromanaging stuff to be small
>> was a thing that extensively did. The embedded libc du jour was uClibc which
>> could chop out all sorts of stuff from its build, so you couldn't be sure things
>> like regex support were there.
>>
>> My opinion of that has gradually changed (micromanaging like that _is_ a form of
>> complexity), and these days I've been ripping config items out of toybox
>> commands, so "using the toybox version of this command" gives you consistent
>> behavior.
>>
>> I've still got options in cat (historical reasons, the whole "cat -v considered
>> harmful" thing), cp --preserve, tail (seek mode), help -ah, netcat's server
>> options, and the truly sad password checking heuristics in passwd.
>>
>> And really, none of them justify their existence. (There were _reasons_ for them
>> all, but... Yes I was argued into adding -v back to cat and didn't like it, but
>> as long as it's there... And the passwd heuristics just plain shouldn't BE
>> there, it should have some way to call out to a password validity checker and
>> NOT try to build in its own half-assed checks...)
>>
>> The whole help text processing infrastucture was to splice together multiple
>> help entries based on what config was enabled, and if this can go that can go.
>> (Or at least be greatly simplified, I still need to _generate_ the header and
>> it's a heavy lift for sed. Might be doable though...)
>>
>> That said, this bug was triggered by a global "do you want to build in selinux
>> support" and THAT's there because not all systems have that.
> 
> (strictly: security contexts. there's smack too.)

Indeed. Thought about it, but didn't add a parenthetical. And didn't remember
the generic term.)

>> I worry that a
>> toolchain won't have it when you cross compile to a small target where the build
>> has switched off xattr support, or on macos or bsd. Hmmm. It mostly has stub
>> functions in the headers to NOP this out, having a dead command line option when
>> the build environment can't do it isn't the end of the world. (Probably should
>> have an error message if you try though... Eh, throw it on the todo list...)
> 
> well, you should get an error if you try to _set_ a security context,
> but isn't the right behavior if asked to show the security context to
> show that there isn't one? my desktop linux box's ls has -Z, but
> correctly shows that there aren't any security contexts.

It was more "built without security context support". The freebsd_miniconfig and
macos_miniconfig have LSM_NONE. (Well, they don't mention it all and LSM_NONE is
the default: miniconig. :)

> there's a similar (well, "related but opposite"?) issue with toybox ls
> that i've been meaning to mention... the GNU behavior when it can't
> stat is that as long as it doesn't _need_ the struct stat, it just
> carries on. so `ls` in a directory with files you can't stat looks
> completely normal. whereas toybox gives an error for each failed stat,
> and then misses the names out of the list for those it couldn't stat.

*nods* That should be fixed. (Fail open vs fail closed is a design decision,
xwrap.c defaults to "fail closed"...)

> i did consider adding a new DIRTREE_ option, but as long as no-one but
> me seems to have noticed this, i've been ignoring it and waiting for
> someone with a stronger opinion to come along.

I noticed it. I added a todo item to one of my lists. But mine wasn't about
suppressing warnings, because I'm getting the warnings in 14.04. Mine was about
adding ? field support:

$ chmod -x toys
$ ls -l toys
ls: cannot access toys/example: Permission denied
ls: cannot access toys/posix: Permission denied
ls: cannot access toys/pending: Permission denied
ls: cannot access toys/other: Permission denied
ls: cannot access toys/lsb: Permission denied
ls: cannot access toys/android: Permission denied
ls: cannot access toys/net: Permission denied
total 0
d????????? ? ? ? ?            ? android
d????????? ? ? ? ?            ? example
d????????? ? ? ? ?            ? lsb
d????????? ? ? ? ?            ? net
d????????? ? ? ? ?            ? other
d????????? ? ? ? ?            ? pending
d????????? ? ? ? ?            ? posix
$ toybox ls toys
ls: toys/example: Permission denied
ls: toys/posix: Permission denied
ls: toys/pending: Permission denied
ls: toys/other: Permission denied
ls: toys/lsb: Permission denied
ls: toys/android: Permission denied
ls: toys/net: Permission denied

And, of course, a test case. :)

>> Oh, speaking of which, the probe for android:
>>
>>   # Some commands are android-specific
>>   probesymbol TOYBOX_ON_ANDROID -c << EOF
>>     #ifndef __ANDROID__
>>     #error nope
>>     #endif
>>
>> Is not triggering when I do:
>>
>> LDFLAGS=--static
>> CROSS_COMPILE=~/android/android-ndk-r19b/toolchains/x86_64-4.9/prebuilt/linux-x86_64/bin/x86_64-linux-android-
>> make distclean defconfig
>>
>> Do I need to #include something to get that symbol, or is not in the NDK 19? My
>> menuconfig android menu's always empty because of that...
> 
> no, __ANDROID__ should be set by the compiler *if* it's targeting an
> Android triple. that implies that the compiler invocation in question
> doesn't think it is?

Blah, I got suckered by that darn double path again. Should be:

  android/android-ndk-r19b/toolchains/llvm/prebuilt/linux-x86_64/bin

(When I tab complete under "toolchains" I keep missing "llvm" among the various
architecture targets, and keep going down the wrong branch.)

It barfs when you try to _build_ without the right $CC in your path, but
genconfig.sh is just turning that into "all probes fail". Lemme fix that...

I used the bash builtin "command -v" instead of which in hopes of not tripping
up bsd and macos, but I suppose they need a working which too? Juggling too many
balls just now...

Rob