[Toybox] mknod: -m not working without MKNOD_Z

[enh]

On Thu, Mar 21, 2019 at 1:55 PM Rob Landley <rob at landley.net> wrote:
>
>
>
> 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. :)

interesting. i get the same behavior for -l, but the behavior i
described for regular ls with "ls (GNU coreutils) 8.28". so maybe they
noticed and fixed that themselves in the last few years? perhaps also
because of security contexts (which is where i hit this, though i too
tested coreutils using `chmod -x` instead)?

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

at some point i'll grab a mac again and have another go. (at fixing
more toys too.) but mac stuff is very low down my to-do list.

> Rob