I have been wondering for quite some time now; where does Android store it's 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 it's own uid and gid and this is the bases 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 Postres and it's 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 it's use usually depends on the application that interprets it.
- I do understand the
packages.list
file with the exception of thenull
entry in the last column, can anyone explain that?
No comments:
Post a Comment