[Toybox] mknod: -m not working without MKNOD_Z

[enh]

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

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

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

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

> Rob