Where is user/group id info stored on Android and how do I interpret it?

Question

I have been wondering for quite some time now; where does Android store its user and group id information?

For instance, on standard Linux, user and group information is stored in /etc/passwd and /etc/group, respectively. When you add a user to a group, his or her username/uid gets added to the list of users in that group, for instance the my audio group entry in /etc/group looks like this:

audio:x:29:pulse,edge-case

Where pulse gets mapped to the uid of the pulseaudio daemon and edge-case gets mapped to my uid (1000), on my Linux box.

As I understand it, each app that gets installed on Android gets its own uid and gid and this is the basis of the "sandboxing" of apps that occurs on Android as they all run in their own process and can't access data of another process or files owned by another app unless there are declaration in a Manifest file created by app programmers which dictates what info is to be shared to other apps and what not. This is also how apps gain or rather request access to networking services during installation by requesting to be added to the INTERNET group or something like that, don't quote me on the name of the NET net group, it might be more like INET or INET6, either way I know there are several levels of network access that can be granted to an application through this mechanism on Android.

My question is, where is this information stored in Android?

Further more, is it possible to modify?

I would like to integrate a glibc stack with it and the data within it in my /etc/{passwd,group} files, trust me, they exist on my phone, I even have apt installed with a lot of other goodies.

Update: Have been doing more searches and This might be what I am looking for.

I will need to dig a bit deeper and make sure it is everything I am looking for.

Update: (5:40 June 27 2014)

Since someone thinks I don't know what I am doing or talking about, let me clarify;

User UIDs on Android are offset with 100000 and App UIDs are offset with 10000 when mapped to the user number _ app number, hence when a ps shows something like u0_a10 which means that User with UID 100000 is running app with UID 10010,

I have pulled UID and user/daemon names from system/core/include/private/android_filesystem_config.h and used those to update my /etc/passwd and /etc/group files (On my Android box), for example my /etc/passwd file (on my Android box) looks like this :

....
brainard:x:100002:100002:Professor Brainard,0420,,:/home/brainard
:/bin/bash
radio:x:1001:1001::/data/radio:/bin/false
bluetooth:x:1002:1002::/data/bluetooth:/bin/false
graphics:x:1003:1003::/home/graphics:/bin/false
input:x:1004:1004::/home/input:/bin/false
camera:x:1006:1006::/home/camera:/bin/false
log:x:1007:1007::/home/log:/bin/false
compass:x:1008:1008::/home/compass:/bin/false
mount:x:1009:1009::/home/mount:/bin/false
wifi:x:1010:1010::/home/wifi:/bin/false
adb:x:1011:1011::/home/adb:/bin/false
install:x:1012:1012::/home/install:/bin/false
media:x:1013:1013::/home/media:/bin/false
dhcp:x:1014:1014::/home/dhcp:/bin/false
....

I have set up configuration in /etc/adduser.conf to create new users like so ( On my Android box) :

# FIRST_[GU]ID to LAST_[GU]ID inclusive is the range of UIDs of dynamically
# allocated user accounts/groups.
FIRST_UID=100001
LAST_UID=199999

FIRST_GID=100001
LAST_GID=199999

This is in accordance with Android's policy, I let "glibc based" system users still be created from range 100-999 I believe and I modified the audio user on my /etc/passwd and /etc/group files to be of 1005, like it is on Android.

I need to update Android and synchronize it with info regarding my User UIDs as well as with my Daemon or system user UIDs from the glibc stack.

You can read more about this in the book "Embedded Android" by Karim Yaghmour Sold here

My goal is to get programs like nvlc to work but I need to get UIDs and GIDs synchronized so that Android is aware of my users and the groups they belong to so that for instance, my brainard user with have access to the audio devices.

Also I need to inform Android about Postgres and its membership in the network group so that it can open sockets and allow access to databases. I have disabled PARANOID_NETWORKING in the kernel for the time being, but this hack only serves to make Android as Secure as vanilla Linux, no less. It would be nice to keep the paranoid setting and apply the group permissions to what daemons/users I see fit.

This would make Android a great operating system for public facing servers with such paranoid and fine tuned controls. Imagine having access to Kerberos, LDAP, PAM, or When using you phone as WAP having Radius configured, all of which are available from Debian and other distribution repos free of charge.

I have got this all figured out, I just need to know how to update Android's UID/GID database, which does get updated every time you install an app, so I know it is possible.

Update : (7:08pm June 30, 2014)

After going over the data in the following files ...

/data/system/packages.list
/data/system/packages.xml
/data/system/user/userlist.xml
/data/system/user/0.xml

... I have updated my question to include "how do I interpret it?"

• I think I am going to need to create a custom PAM module and blend Bionic and Glibc into a single C library, they need to compatible with applications on both sides, no exceptions, expect C++ exceptions that is ;p--- I have written a couple rules of thumb-2 :) for myself to follow. I might also need to write a wrapper to popular package management systems like rpm and apt that fakes an apk installation and gives each new deb|rpm package a UID and maybe just sym-link everything into the FHS. That might be the most ideal solution I could go for, though the most work, as each would need a set of permissions in their "manifest", maybe a menu during install an the user can give and take as needs be.
• Does anyone have a good reference that explains the syntax of these files? I am not very well versed with XML, not to mention its use usually depends on the application that interprets it.
• I do understand the packages.list file with the exception of the null entry in the last column, can anyone explain that?

Answer 1

Here my thoughts on how Android implements UID/GID lookup. I hope it will be helpful to anyone who is having the questions.

grp_pwd.cpp describes how Android translate a UID/username to a passwd structure. From the getpwuid function we can see that

1. The UID is first compared to the predefined AIDs from generated_android_ids.h under $(AOSP_ROOT)/out/soong/.intermediates/bionic/libc/generated_android_ids/gen which is generated from android_filesystem_config.h according to bionic/libc/Android.bp and bionic/Android.bp. The AIDs are stored in a username to UID map in struct android_id_info android_ids[] and when looked up, they are converted to the passwd structure with uid and gid set to AID, home directory set to / and shell set to /system/bin/sh (code).

2. If no user is found in the previous step, the function will look for OEM defined users. The UIDs of these users range from AID_OEM_RESERVED_START to AID_OEM_RESERVED_END and AID_OEM_RESERVED_2_START to AID_OEM_RESERVED_2_END. The vendor-defined users are stored in /vendor/etc/passwd. User names are set to oem_${uid} and the other attributes are set in the same fashion as the AID users.

3. Finally, it will check all app users in app_id_to_passwd() and the process is very similar.

If you wish to get all passwd entries, please take a look at getpwent() in the same file and also the manpage of getpwent(3)

Answer 2

Seen the GET_ACCOUNTS permission? (Ed. Note: That particular feature might not be every useful for this question, either, as it is apparently a feature developed moreso for web authentication.)

Personally, I'm reading about the topic as with regards to UID/GID values computed at time of APK install – presently, as research for a simple 'blog article -- but I would like to study this topic a little further, too. Referring to the reference documentation about these multiply-linked OS features, in Android, it seems there is an Account Service in the Android OS. (Ed. Note It may seem, furthermore, that the Account Service in Android may be more a service developed for application about an Android user's web accounts)

Though personally I'm preoccupied about writing another article, immediately, but certainly the Account Service may bear some further study. Perhaps it may be relevant, orthogonally, as with regards to applying Kerberos on Android appliances. There is some of an existing work, with regards to implementing Kerberos services on the Android platform. For web apps, of course there's OAuth/OAuth2.

Evidently, Android does not use conventional UNIX passwd/shadow files(Anderson2013). My best estimate, presently, is that the Android OS Account Service may be a topic to a manner of a further study ... at least, so far as to discover that the Android Account Service may be rather a web authentication utility(API: AccountManager).

I'm sure there's something more about Android's alternative to /etc/passwd, somewhere in the Android source code. Hopefully, it's close to however the same thing might be approached in CyanogenMod.

Answer 3

First of all as you are aware of that the every Application has its own unique PID(Process ID) this PID is assigned to the application by the kernel of the Operating System.

1. In Android ADT you can off course view the PID in the logcat .
2. If you want to view the PID in your device then you need to install an Application from the play store(can't give any guarantee whether the PID displayed by the app is genuine or not)
3. Coming to the modification part is a big No.
4. No you cannot modify the PID as your wish as it will lead to security concerns as well as ambiguity between the apps for another app may have the same PID thereby resulting to Conflict.