[Toybox] ls -l / doesn't work on pie.

[enh]

On Thu, May 30, 2019 at 4:29 PM Rob Landley <rob at landley.net> wrote:
>
> I installed terminal on my new phone and the first command I ran was "ls -l"
> which said:
>
>   ls: .: Permission denied
>
> Which seems to be the same problem as 527045debecb but my question is are you
> intentionally trying to prevent readdir() on / (so the command line is kinda
> useless because you don't know what directories you can descend into) or do I
> just need to add O_PATH to the open in dirtree() and allow stat() to fail in
> some circumstances?
>
> (How I tell it's a directory if stat failed is an interesting question, but I
> guess in that case I can just _try_ to descend and see if I get a different error?)
>
> What exactly did this selinux addition defend against, anyway?

so the _shell_ isn't useless --- terminal apps are useless^Wless
useful. shell as in `adb shell` runs as the shell user (or root if you
[can] `adb root`), and that's a much weaker SELinux domain meant for
debugging/testing. terminal apps are (unsurprisingly) apps, so they
have all the usual restrictions from an untrusted_app SELinux domain.
(these days there are several of these, for different target API
levels, but the big picture is that apps can do a lot less than a
[typically `adb shell`] user in the SELinux shell domain.)

this isn't actually a security think. SELinux just happened to be a
useful hammer here. this is actually about app compatibility. there's
a subset of apps that assume that a certain directory layout exists,
and depend on that layout. this slows down development, as we then
have backwards compatibility requirements we need to maintain. (random
example: you'd be surprised how many [more than zero] apps made
assumptions about where libc.so lives on the file system. they broke
in Q.)

everything in / is an implementation detail, and we don't want apps
assuming our implementation can never change. philosophically, the
only thing apps should have visibility into is their personal
/data/data directory. we're not enforcing a security guarantee here:
the goal is just to enforce architectural separation of concerns, so
that Android can iterate independent of Android's apps.

for me the `adb shell ls -l /` case on a non-rooted device is more
interesting. something like:

$ adb shell ls -l /
total 52
dr-xr-xr-x  29 root   root       0 1970-08-02 16:18 acct
drwxr-xr-x  10 root   root     200 2019-05-09 21:45 apex
lrw-r--r--   1 root   root      11 2019-05-09 20:36 bin -> /system/bin
...
drwxr-xr-x  13 root   root    4096 2019-06-03 15:23 system
drwxr-xr-x  16 root   shell   4096 2019-05-23 01:49 vendor
ls: //init.zygote32.rc: Permission denied
ls: //init.rc: Permission denied
ls: //metadata: Permission denied
ls: //init.recovery.blueline.rc: Permission denied
ls: //init.recovery.crosshatch.rc: Permission denied
ls: //init.usb.rc: Permission denied
ls: //init.environ.rc: Permission denied
ls: //init.usb.configfs.rc: Permission denied
ls: //init.recovery.sdm845.rc: Permission denied
ls: //ueventd.rc: Permission denied
ls: //postinstall: Permission denied
ls: //init: Permission denied
ls: //cache: Permission denied
ls: //adb_keys: Permission denied
ls: //init.zygote64_32.rc: Permission denied
$

that seems odd, and we've talked about GNU's use of ??? before, but i
could also see an argument that the current output would be fine too
_if_ the errors were sorted in with the successes.

iirc your counterpoint at the time was that removing the `-l` should
put us back in a situation that just works but we'd still get
(pointless) "Permission denied" errors, and that's the argument why
GNU-style ??? is better for data you don't have.

> Rob