Aquí está lo que he averiguado hasta ahora, corrígeme si me equivoco.

Permisos de archivo de Android 13 en la partición de datos

Los permisos se almacenan en el inodo de un archivo o directorio.

• ls -a y similares muestran los permisos tradicionales.
• lsattr se usa para ver los atributos. lsattr y chattr están presentes en mi OnePlus 8 Pro con Android 13 en /system/bin. (Solo funcionan con un sistema de archivos compatible, de lo contrario, error 'Inappropriate ioctl for device'.)
• getfattr es una herramienta general para ver los atributos extendidos - XATTR. (Existen herramientas más especializadas para atributos específicos como getfacl, getcap, ls -Z, etc.)
  Dentro de Termux pkg install attr para obtener las herramientas getfattr y setfattr.
  (setfattr solo funciona con un sistema de archivos compatible, de lo contrario, error 'Operation not supported on transport endpoint'.)
  El uso de getfattr es un poco engorroso. De forma predeterminada, solo muestra el espacio de nombres del usuario. Para mostrar todos, la forma recomendada es
  getfattr -d -m ^ -- archivo_o_directorio
  getfattr -d -m ^ -R -- archivo_o_directorio      recursivamente
  (-m ^ coincide con el inicio de cualquier cadena sin necesidad de escapar el parámetro, el doble guion -- es necesario como separador en caso de que el nombre de archivo o directorio empiece con un guion)

Linux implementa una amplia gama de conceptos de permisos diferentes.

• DAC, Control de Acceso Discrecional, es la seguridad tradicional de Linux con los bits rwx más las funciones avanzadas setuid, setgid, sticky.
  No hay diferencias en comparación con un sistema funcional. No hay cambios en el comportamiento cuando doy permisos 777 a archivos y carpetas para hacer pruebas.
• ACL, Listas de Control de Acceso, según he leído, supuestamente no se utilizan en Android.
  Sin embargo, tenía muchas etiquetas de ACL adjuntas como XATTR. Solo en /data/media/0 y debajo. Samba, aunque no configurado para usar ACL, etiquetó el directorio superior de la compartición con system.posix_acl_default. Esto ha sido heredado por todos los archivos y directorios debajo.
  setfattr no funciona recursivamente por sí mismo. Así que usé 'find' que también muestra archivos ocultos. He eliminado todas las etiquetas inútiles con:
  find 0 -exec setfattr -h -x system.posix_acl_default {} ;
  find 0 -exec setfattr -h -x system.posix_acl_access {} ;
  Aunque no está relacionado con mi problema.
• Las capacidades ambientales se establecen en el /system/etc/init/*.rc para procesos de arranque y servicios.
  Determinan qué procesos pueden ejecutar qué funciones y qué recursos se les permite utilizar.
  El contenido de /system/etc/init es idéntico en ambos sistemas. No creo que tenga algo que ver con mi problema.
• Atributos adjuntos a los archivos.
  La página man de chattr enumera todos los atributos posibles. En la partición de datos hay principalmente E (encriptado), I (indexado), N (datos de inodo presentes), a veces e (extensiones de bloque). Estas son todas características de cómo se almacena el archivo, no control de permisos típico. Grandes cantidades de archivos tienen la misma combinación de atributos configurada.
  Solo en cuatro archivos vi V (fs-verity) configurado.
  No noté ninguna diferencia relevante con el sistema funcional.
• Capacidades de archivos como XATTR adjuntas a los archivos.
  Los derechos de acceso de un proceso son verificados por el kernel contra las capacidades asignadas a un archivo. Las capacidades de archivo se almacenan en una forma codificada. getcap puede descifrarlo a una forma legible para humanos. Se almacenan en un atributo extendido llamado security.capability.
  En mi partición de datos no tengo ni un solo security.capability, sin embargo.
  Lo que tengo y donde el valor parece un poco como una capacidad codificada son atributos como:
  user.inode_cache=0szRUAAAAAAAA=
  user.inode_code_cache=0szhUAAAAAAAA=
  user.inode... solo está adjunto a cada directorio de aplicaciones en /data/data y /data/user/0, en ningún otro lugar. No sé qué es. La secuencia de caracteres es diferente para cada directorio y diferente al sistema funcional.
  Otra cosa interesante:
  user.serial="0" adjunto a /data/data, /data/misc_ce/0, /data/system_ce/0, /data/system_de/0, /data/user/0, /data/user_de/0
  user.extdbsessionid0 y user.uuid adjuntos a com.google.android.providers.media.module/databases/external.db en /data/data y /data/user/0
  user.extdbnextrowid0 y user.extdbsessionid0 adjuntos a /data/media/0
  Todas las ID son diferentes al sistema funcional.
• MAC, Control de Acceso Obligatorio de SELinux, verifica los procesos y el acceso a archivos basados en políticas centrales en /system/etc/selinux.
  El contexto del archivo está adjunto como XATTR. Para verlo con getfattr o más fácil con ls -Z.
  cat /proc/kmsg | grep avc: muestra mensajes de registro de SELinux. Estos se envían a dmesg, y según he leído, también a logcat.
  cat /sys/fs/pstore/console-ramoops-0 | grep avc: supuestamente muestra mensajes del arranque previo.
  En mis registros he visto extremadamente pocos mensajes avc:. Y ninguno relacionado con los mensajes de error/fallos en el primer post. Aunque establecer el contexto de archivo SELinux correcto ayudó contra los mensajes de error de 'permiso denegado'.
  Hay muchas diferencias en los contextos de archivos con el sistema funcional. Así que comencé a corregir carpetas y archivos individuales por ejemplo con
  setfattr -n security.selinux -v u:object_r:app_data_file:s0:c153,c256,c512,c768 com.oneplus.calculator
  Descubrí que obtengo el mismo resultado usando restorecon. Se utiliza para corregir contextos incorrectos. Restablece el contexto predeterminado de archivos y directorios basado en las políticas centrales de SELinux.
  Según la documentación, restorecon debería funcionar de forma recursiva con el parámetro -R, pero no lo hizo. Un constructo con 'find' realiza el trabajo:
  find com.oneplus.calculator -exec restorecon -v {} ;
  Con eso, los errores de permiso denegado ya no ocurren.
• Encima de todo esto, tenemos el control de permisos basado en el manifiesto de aplicaciones de Android en el marco de Java. Cosas como ACCESS_FINE_LOCATION.

Así que al final, establecer el contexto de archivo SELinux correcto ayudó contra los errores de permiso denegado en mi publicación original.
Todavía estoy investigando esto. Hasta ahora, no he sido tan audaz como para ejecutar restorecon en toda la partición de datos.

Saludos cordiales,
Zweikeks