An observation about UIDs under Android, and what that means for running Linux under Android.

In this earlier posting I had written, that I had installed Linux on my Android tablet, that being the Samsung Galaxy Tab S, First Generation, and that I had done so without rooting the tablet, and without using any kind of image-file that can act as a virtual drive, via a kernel loop-mount.

Simply using this arrangement makes something obvious to me, which I have already known.

Under Android, the userids which the kernel keeps for file-ownership are one userid per app. Hence, when we run Linux on it, all the processes really have the same userid, that being the userid of the app ‘GNURoot’ in my case. The ‘chown’ and ‘chmod’ commands have no effect. This is what a regular ‘ls -al’ command reveals:

 


total 100
drwxrwx---.  2 root 9997  4096 Sep 27 17:03 .
drwxrwx---. 25 root 9997  4096 Sep 26 15:27 ..
-rw-rw----.  1 root 9997     0 Sep 27 17:03 dir_listing.txt
-rw-rw----.  1 root 9997     8 Sep 26 03:07 test_1.aux
-rw-rw----.  1 root 9997  5625 Sep 26 08:28 test_1.fdb_latexmk
-rw-rw----.  1 root 9997  5473 Sep 26 03:07 test_1.fls
-rw-rw----.  1 root 9997 18213 Sep 26 03:07 test_1.log
-rw-rw----.  1 root 9997 38253 Sep 26 03:07 test_1.pdf
-rw-rw----.  1 root 9997  1467 Sep 26 03:07 test_1.synctex.gz
-rw-rw----.  1 root 9997   734 Sep 26 08:28 test_1.tex
-rw-rw----.  1 root 9997   734 Sep 26 03:07 test_1.tex~


 

(Edit 10/08/2017 :

Here, the Android O/S itself and its (Dalvik) bytecode interpreter / flash-compiler, run as root. )

I can use the ‘adduser’ command to create a userid, which only my fake-rooted Linux system sees, and doing so assigns a useless password, but aside from that, only helps Linux organize personal data into a defined home-folder. Even if I was to proceed to launch my desktop manager as (fake) user ‘root’, as the Android kernel sees things, all the resulting processes would run as belonging to the same userid, as when I run the desktop manager as my created userid, that real userid still belonging to the one app ‘GNURoot’.

One effect this does have, is that if I use ‘GVim’ to edit a file and save the changes, I get a warning, that my userid does not have write-permissions for that file. Yet afterward, the new version of the file has been saved. Also, data which that Linux system’s applications store, does get stored. This appears to result, because GVim only looks at the UID before displaying that message, while the GID would suggest I have write-permission.

But it can become a little bit more interesting, if I use some other, non-Linux app, to store a file in one of my Linux-subfolders, and then want to alter those files from within Linux. That other, Android, file-management app has its own userid. And then there is one reason why each Android app can read the data of the other:

Each userid belongs to one group-id as well as numerous others, determined by the Android host system, that was granted because we gave both apps the permission to read and write files personally belonging to the Android user.

But, we cannot change the permission bits ourselves, nor the ownership, because we don’t really have root.

(Updated 09/29/2017 : )

Now, If the applications continue to work, and if I can finally transfer my information into and out of Linux, and still be able to read it afterward either way, then I should regard this situation as par for the course.

Interestingly, the concept can also exist within Linux, to use ‘chroot’ and to force certain applications to run inside a jail. In fact, some Linux programs specifically detect that they are running in a ‘chroot-ed’ environment, and make programmed decisions based on that.

(Edit 09/28/2017 : )

As my description implies, the applications which run in this kind of ‘chroot jail’ , are capable of detecting the environment as being that, and also, certain Linux applications may not run, for only that reason.

Further, I’ve already found out, that certain applications such as ‘gnome-mplayer’ fail to save my configuration-settings, from one launching to the next. The reason for this is the fact that on a ‘real’ GNOME-based Linux system, there are services running alongside the user-processes, such as the ‘GNOME Configuration Daemon’. When we tell the Linux package manager to install services, while running it inside our chroot jail, if we look at the post-install-messages, we’ll see a message something like this:

Detecting chroot environment. Deferring Server Start.

What this means is that when I run GNURoot specifically, there could be any number of system processes not running, that under ‘real’ Linux would be running. Only the processes will be running, that have as their parents, the console from which I launched LXDE, and which would normally belong directly to the Linux user in question.

Further, if we want to run processes under ‘real’ Linux, inside a jail, then there are three components to what must be done:

  1. ‘chroot’ must be executed, its main effect being, that the top-most directory which the chosen parent-command sees will be the specified ‘New Root Directory’
  2. The options would need to be given to ‘chroot’, to change the userid and/or group-membership of the chosen process, since by default, that process runs with the same privileges as the process that invoked ‘chroot’ (usually root).
  3. The directory-tree which has been chosen may need to be manipulated under a Linux system. such that the chosen UID and GIDs of the specific process will have whatever limitations we’d like to give it, with respect to modifying files and directories.

In other words, when the ‘ls -al’ command mentioned above shows us that the access to the files and directories for ‘other’ – i.e. For users that do not own the files, nor For groups which the user belongs to, including the group which any given file belongs to – Is completely set to zeroes, this is not a temporary, virtual product of what the kernel would do. It’s just how the files have genuinely been set up within that directory and its sub-directories: ‘chmod o-rwx’ .

Because the ability of a process to change its userid requires that that process initially be running as real root, part (2) above can only be carried out, if the process that calls the ‘chroot’ command is initially root. Otherwise, the possibility might exist, for non-root processes to call ‘chroot’ .

Because this might be a bit complicated for some Linux users to manage, it would not surprise me if under Linux, utilities exist which combine all three steps needed above, and which simplify running a process in a jail – when running under real Linux. Personally, I’ve never needed to do such a thing, aside from wanting to run Linux under Android.

(Edit 10/08/2017 : )

One conclusion which the reader might draw from this posting so far, would have been, that Android relies on such File-GID-settings to control the Android security policy. But alas, this would be untrue.

By default, Android apps are programmed in Dalvik, which means that its Bytecode interpreter / flash-compiler – similarly to the Java Virtual Machine – has a more-complex security model, and that its security model trumps that of the files’ group-membership, because the interpreter itself, or the Android Run-Time, runs as root.

Not only that, but modern Android (v6+) devices have processes running in the BG, which periodically check the file attributes, and which make minor corrections to those, should they not be correct.

I know this, because using my chroot-environment Linux shell, I’ve gotten a listing of directory attributes, where all the files except one have a certain ~correct~ GID, while one file had a GID not consistent with the rest, that file having been placed there by a different, file-manager application.

And without actions from me, one day later, that one file had a GID consistent with the others.

Also, I’m noticing that GVim has stopped complaining, when commanded to save changes to a given file.

So while Android security policies affect the use of a Linux subsystem, the reverse does not follow. Indeed, the feat should be respected, that Linux package maintainers have been able to cross-compile their whole repositories – excepting certain packages – into ARM-CPU object-code, that being ‘Native Code’, while Android developers are encouraged to write the bulk of their applications in Dalvik, not in native code.

The simple fact that the packages can be cross-compiled in this way, is not enough to guarantee however, that Linux will run on the given architecture. One feat which Linux devs may not have achieved yet, is to get their X-server running… I can think of two reasons:

  1. If Android is already running, then an X-server cannot ‘grab’ the display device, because Android already controls it.
  2. Even though all the source-code belonging to a real X-server could be compiled correctly, normally, the X-server only has a fixed set of modules, which are part of a package, and which recognize specific graphics chip-sets. Those chip-sets have traditionally been PC and laptop graphics cards – i.e. known GPUs. I don’t think that X-server modules have ever been written that recognize tablet- or phone- GPUs.

Hence, if a private user wanted to install pure Debian on his ?tablet? , he’d need to boot that without Android running, and might then face the risk, that his X-server, and thus his entire touch-screen, don’t start… Therefore, it remains easier, to run Linux under Android in some way, and as I did, rely on an Android app to emulate the X-server.

I have not undertaken any misadventure yet, to try custom-compiling something, which I cannot obtain from the package manager – on my Android devices. Firstly, I’m not even sure that the gcc / g++ compiler-packages themselves have been cross-compiled. And secondly, their use would also imply, that I’d be compiling complex source-trees to ARM Native Code. That just strikes me as a strange thing, ever to do.

So I could compile C or C++ source code, but only in such a way that it runs on an ARM CPU, and in such a way, that it needs to link to Linux shared libraries? A strange proposition indeed.

Dirk

 

Print Friendly, PDF & Email

Leave a Reply

Your email address will not be published. Required fields are marked *

Please Prove You Are Not A Robot *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>