Me he estado preguntando por bastante tiempo ahora; ¿Dónde almacena Android su información de identificación de usuario y grupo?
Por ejemplo, en Linux estándar, la información de usuarios y grupos se almacena en /etc/passwd
y /etc/group
, respectivamente. Cuando agrega un usuario a un grupo, su nombre de usuario / uid se agrega a la lista de usuarios en ese grupo, por ejemplo, la entrada de mi grupo de audio se /etc/group
ve así:
audio:x:29:pulse,edge-case
Donde el pulso se asigna al uid del demonio pulseaudio y el caso de borde se asigna a mi uid (1000), en mi caja de Linux.
Según tengo entendido, cada aplicación que se instala en Android tiene su propio uid y gid y esta es la base del "sandboxing" de las aplicaciones que se produce en Android, ya que todas se ejecutan en su propio proceso y no pueden acceder a los datos de otro proceso o archivos propiedad de otra aplicación a menos que haya una declaración en un archivo de manifiesto creado por los programadores de la aplicación que dicta qué información se debe compartir con otras aplicaciones y qué no. Esta es también la forma en que las aplicaciones obtienen o más bien solicitan acceso a los servicios de red durante la instalación al solicitar que se les agregue al grupo INTERNET o algo así, no me cite el nombre del grupo NET NET, podría ser más como INET o INET6, de cualquier manera, sé que hay varios niveles de acceso a la red que se pueden otorgar a una aplicación a través de este mecanismo en Android.
Mi pregunta es, ¿dónde se almacena esta información en Android?
Además, ¿es posible modificar?
Me gustaría integrar una pila glibc con ella y los datos que /etc/{passwd,group}
contiene en mis archivos, confía en mí, existen en mi teléfono, incluso tengo instalado con muchas otras cosas.
Actualización: He estado haciendo más búsquedas y esto podría ser lo que estoy buscando.
Necesitaré profundizar un poco más y asegurarme de que sea todo lo que estoy buscando.
Actualización: (5:40 27 de junio de 2014)
Como alguien piensa que no sé lo que estoy haciendo o hablando, déjenme aclarar;
Los UID de usuario en Android se compensan con 100000 y los UID de aplicaciones se compensan con 10000 cuando se asignan al número de usuario _ número de aplicación, por lo tanto, cuando un ps muestra algo como u0_a10, lo que significa que el usuario con UID 100000 está ejecutando la aplicación con UID 10010,
Extraje el UID y los nombres de usuario / daemon del sistema / core / include / private / android_filesystem_config.h y los usé para actualizar mis archivos / etc / passwd y / etc / group (en mi cuadro de Android), por ejemplo mi / etc / El archivo passwd (en mi caja de Android) se ve así:
....
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
....
He configurado la configuración en /etc/adduser.conf para crear nuevos usuarios así (en mi caja de Android):
# 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
Esto está de acuerdo con la política de Android, dejo que los usuarios del sistema "basados en glibc" sigan siendo creados desde el rango 100-999, creo, y modifiqué el usuario de audio en mis archivos / etc / passwd y / etc / group para que sean 1005, como Está en Android.
Necesito actualizar Android y sincronizarlo con la información relacionada con mis UID de usuario, así como con mi Daemon o UID de usuario del sistema de la pila glibc.
Puede leer más sobre esto en el libro "Embedded Android" de Karim Yaghmour Vendido aquí
Mi objetivo es hacer que programas como nvlc funcionen, pero necesito sincronizar los UID y GID para que Android conozca a mis usuarios y a los grupos a los que pertenecen, por ejemplo, mi usuario de Brainard tiene acceso a los dispositivos de audio.
También necesito informar a Android sobre Postres y su membresía en el grupo de red para que pueda abrir sockets y permitir el acceso a bases de datos. Por el momento, he deshabilitado PARANOID_NETWORKING en el kernel, pero este truco solo sirve para hacer que Android sea tan seguro como Vanilla Linux, nada menos. Sería bueno mantener la configuración paranoica y aplicar los permisos de grupo a los demonios / usuarios que considero adecuados.
Esto haría de Android un gran sistema operativo para servidores públicos con controles tan paranoicos y ajustados. Imagine tener acceso a Kerberos, LDAP, PAM o Al usar su teléfono como WAP con Radius configurado, todos los cuales están disponibles en Debian y otros repositorios de distribución de forma gratuita.
Tengo todo esto resuelto, solo necesito saber cómo actualizar la base de datos UID / GID de Android, que se actualiza cada vez que instala una aplicación, así que sé que es posible.
Actualización: (7:08 pm 30 de junio de 2014)
Después de repasar los datos en los siguientes archivos ...
/data/system/packages.list
/data/system/packages.xml
/data/system/user/userlist.xml
/data/system/user/0.xml
... He actualizado mi pregunta para incluir "¿cómo la interpreto?"
- Creo que voy a necesitar crear un módulo PAM personalizado y combinar Bionic y Glibc en una sola biblioteca C, deben ser compatibles con las aplicaciones en ambos lados, sin excepciones, esperan excepciones C ++; p --- He escrito Un par de reglas del pulgar-2 :) para que yo mismo las siga. También podría necesitar escribir un contenedor para sistemas de administración de paquetes populares como rpm y apt que simula una instalación de apk y le da a cada nuevo paquete deb | rpm un UID y tal vez simplemente enlace simbólico todo al FHS. Esa podría ser la solución más ideal que podría buscar, aunque la mayor parte del trabajo, ya que cada uno necesitaría un conjunto de permisos en su "manifiesto", tal vez un menú durante la instalación que el usuario pueda dar y tomar según sea necesario.
- ¿Alguien tiene una buena referencia que explique la sintaxis de estos archivos? No estoy muy familiarizado con XML, sin mencionar que su uso generalmente depende de la aplicación que lo interpreta.
- Entiendo el
packages.list
archivo con la excepción de lanull
entrada en la última columna, ¿alguien puede explicar eso?
fuente
Respuestas:
Visto el
GET_ACCOUNTS
permiso? ( Nota del editor : esa característica particular podría no ser útil para esta pregunta, ya que aparentemente es una característica desarrollada más para la autenticación web).Personalmente, estoy leyendo sobre el tema con respecto a los valores UID / GID calculados en el momento de la instalación de APK, actualmente, como investigación para un simple artículo de blog, pero también me gustaría estudiar este tema un poco más. En referencia a la documentación de referencia sobre estas características del sistema operativo con enlaces múltiples, en Android, parece que hay un Servicio de cuenta en el sistema operativo Android. ( Nota del editor. Puede parecer, además, que el Servicio de cuenta en Android puede ser más un servicio desarrollado para la aplicación sobre las cuentas web de un usuario de Android)
Aunque personalmente estoy preocupado por escribir otro artículo, de inmediato, pero ciertamente el Servicio de Cuentas puede llevar a cabo más estudios. Quizás puede ser relevante, ortogonalmente, en lo que respecta a la aplicación de Kerberos en dispositivos Android. Existe un trabajo existente, con respecto a la implementación de servicios Kerberos en la plataforma Android. Para aplicaciones web, por supuesto, hay OAuth / OAuth2.
Evidentemente, Android no utiliza archivos UNIX passwd / shadow convencionales ( Anderson2013 ). Mi mejor estimación, en la actualidad, es que el Servicio de cuenta del sistema operativo Android puede ser un tema para un estudio posterior ... al menos, hasta descubrir que el Servicio de cuenta de Android puede ser más bien una utilidad de autenticación web ( API: AccountManager ).
Estoy seguro de que hay algo más sobre la alternativa de Android
/etc/passwd
, en algún lugar del código fuente de Android. Con suerte, está cerca, sin embargo, lo mismo podría abordarse en CyanogenMod.fuente
Aquí mis pensamientos sobre cómo Android implementa la búsqueda UID / GID. Espero que sea útil para cualquiera que tenga las preguntas.
grp_pwd.cpp describe cómo Android traduce un UID / nombre de usuario a una
passwd
estructura. De lagetpwuid
función podemos ver queEl UID está primero en comparación con el SIDA predefinidos de
generated_android_ids.h
bajo$(AOSP_ROOT)/out/soong/.intermediates/bionic/libc/generated_android_ids/gen
que se generan a partir de android_filesystem_config.h según biónico / libc / Android.bp y biónico / Android.bp . Los AID se almacenan en un nombre de usuario en el mapa UIDstruct android_id_info android_ids[]
y, cuando se buscan, se convierten a lapasswd
estructurauid
y segid
configuran en AID, el directorio de inicio se establece en/
y el shell se establece en/system/bin/sh
( código ).Si no se encuentra ningún usuario en el paso anterior, la función buscará usuarios definidos por el OEM. Los UID de estos usuarios van de
AID_OEM_RESERVED_START
aAID_OEM_RESERVED_END
yAID_OEM_RESERVED_2_START
aAID_OEM_RESERVED_2_END
. Los usuarios definidos por el proveedor se almacenan en/vendor/etc/passwd
. Los nombres de usuario se establecen enoem_${uid}
y los otros atributos se configuran de la misma manera que los usuarios de AID.Finalmente, verificará a todos los usuarios de la aplicación
app_id_to_passwd()
y el proceso es muy similar.Si desea obtener todas las
passwd
entradas, eche un vistazo algetpwent()
mismo archivo y también a la página de manual de getpwent (3)fuente
En primer lugar, como sabe que cada aplicación tiene su propio PID (ID de proceso) único, este PID es asignado a la aplicación por el núcleo del sistema operativo.
fuente