[Toybox] [PATCH] toybox SELinux chcon

[Rob Landley]

On 12/10/14 22:52, enh wrote:
> here's a patch that should let us replace toolbox's chcon. (it also
> adds a feature, -R, because toybox makes that so easy.)
> 
> you'll probably want fancier configuration here because although the
> --as-needed works okay, a typical Ubuntu box will have the .so but not
> the .h files.

That's what the compile time probes in scripts/genconfig.sh are for. Try
to compile a C snippet and set a config symbol based on whether or not
the .o file created without error.

Alas, that mechanism can't actually run the result because we could be
cross compiling, but in this case "is the .h file there" is an easy check.

> i did consider adding a toys/selinux/ directory, but
> given that existing tools like ls and id will want -Z SELinux options,
> i wasn't sure whether you'd think it was worth segregating the
> SELinux-only toys.

We can always move things later.

> note that this won't help the tizen smack users (and patch for smack
> won't help SELinux users). so you might want to think about where
> you'd like us to be aiming: #if USE_SELINUX/USE_SMACK in all the
> relevant places, or a toys/selinux and a toys/smack (though we'd still
> need #if in at least ls and id), or a lib/security.c that concentrates
> all the differences into one file?

We actually _can't_ have toys/tizen/chcon.c and toys/selinux/chcon.c
because command names are a flat namespace.

The directories are largely cosmetic, they happened because I wanted to
indicate "this is a posix command", "this is an LFS command", "this is
neither", and couldn't think of a cleaner way to do it. (Putting
"(POSIX)" after command names seemed silly, and adding something to the
menuconfig help text meant it would show up in "commandname --help"
output because that's generated from there.)

That said, the config infrastructure does a neat trick to eliminate #ifdefs:

The menuconfig CONFIG_BLAH symbols are either defined or not defined, so
you have to check them with #ifdef. From those, I generate CFG_BLAH
symbols, which are always defined but are either 1 or 0 depending on
whether they're enabled. (CONFIG vs CFG.) That means you can do:

  if (CFG_BLAH) optional_thingy();

And it drops out at compile time dead code elimination removes if (0)
stanzas (and even if (0 && anything_else), although if (anything_else &&
0) would still have anything_else evaluated for side effects). This
means you always need the function prototype for optinoal_thingy()
whether or not it's enabled, but since the actual function won't get
called if it's disabled, you won't need the library at link time.

I did that back in busybox and they kept doing:

#if CFG_THINGY
  function_call()
#endif

And I would sigh deeply and go back to toybox...

(We also have USE_BLAH() macros which evaluate to what's in the
parentheses if it's enabled, and nothing if it's disabled. These are
used with C's string aggregation ("one" "two" becomes "onetwo") to edit
option strings, and you can drop out varargs, and stuff like that.
That's basically the same as an #ifdef without requiring three lines to
make a small change.)

The thing is #ifdefs can cause config-dependent build breaks, so you
need to test ever possible permutation of your config symbols to make
sure the sucker _compiles_. The if (CFG) stuff shouldn't cause those.
All the code is at least run through the compiler each time, you don't
have "oh I haven't tested that config in ages, it doesn't build anymore"...

Anyway, to answer your _design_ question: we can do compile time probes
for CONFIG_SMACK or CONFIG_SELINUX, have the command "depends on
CONFIG_SMACK || CONFIG_SELINUX", and then if (CFG_SMACK) thingy(); else
if (CFG_SELINUX) thingy(); in command_main();

If their command line arguments vary, that's doable as well but slightly
more complicated.

Rob

 1418353312.0