On Thu, May 30, 2019 at 4:29 PM Rob Landley <[email protected]> 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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
