Estoy usando una Chromebook y me gustaría navegar dentro del contenedor de Android a través del shell. El contenedor se monta en el camino /run/containers/android_XXXXX. Al intentar cdingresar al directorio, me dicen Permission Denied. Intenté ejecutar el comando como sudo, pero por alguna razón el cdcomando se vuelve inaccesible. He consultado chmod u+xel directorio, pero no hay dados.
¿Qué pasos puedo tomar desde aquí?
Lo ejecuté staten el directorio, que devuelve lo siguiente:
File: ‘android_XXXXXX/’
Size: 80 Blocks: 0 IO Block: 4096 directory
Device: fh/15d Inode: 59640 Links: 3
Access: (0700/drwx------) Uid: (655360/ UNKNOWN) Gid: (655360/ UNKNOWN)
Context: u:object_r:tmpfs:s0
Access: 2016-10-31 04:04:52.680000040 +0000
Modify: 2016-10-31 04:04:52.200000040 +0000
Change: 2016-10-31 04:44:54.990001186 +0000
Birth: -
Respuesta1
El directorio es drwx------para que solo alguien cuyo uid sea 655350(que no figura en el archivo de contraseñas) pueda leerlo o ingresarlo.
sudo cdSe espera que no pueda encontrar el cdcomando, es una característica incorporada del Shell. Si no estuviera integrado entonces no funcionaría. Digamos que su shell actual tiene un ID de proceso de 54000, ejecutó el comando /bin/cd, podría ser PID 54309. Cambiaría el directorio para el proceso 54309 y luego saldría. El proceso 54000 todavía estaría en su directorio original.
chmod u+xaltera user (owner)el permiso.
lo que quieres essudo chmod go+rx /run/containers/android_XXXXX
Respuesta2
Además de verificar los permisos como mencionó @icarus, también debe verificar sus ACL (listas de control de acceso) para getfaclasegurarse de que no haya reglas que anulen los privilegios básicos de acceso a archivos.
NOTA: Si getfaclno existe en su sistema, probablemente no sea el problema.
ACL de ejemplo que no debería ser un problema.
$ getfacl test/
# file: test/
# owner: root
# group: root
user::rwx
group::r-x
other::r-x
Esto indica que no se aplican reglas ACL adicionales, aparte de las reglas de acceso POSIX estándar. Puede ver que coincide con la salida ls -alden términos de permisos. (El -dargumento lsle dice que le muestre el directorio en sí, no su contenido).
$ ls -ald test/
drwxr-xr-x 2 root root 4096 May 8 19:11 test/
Ejemplo de una ACL que podría causarle problemas.
$ getfacl test/
# file: test/
# owner: root
# group: root
user::rwx
user:mc:r--
group::r-x
mask::r-x
other::r-x
$ ls -ald test/
drwxr-xr-x+ 2 root root 4096 May 8 19:11 test/
En este caso, al observar el resultado de ls -ald, no pensaría que habría un problema. Sin embargo, debido a que las reglas ACL se aplican sobre las reglas POSIX, el usuario mcno podría cambiar al directorio debido a la falta de permisos ejecutables para él, a pesar de que el conjunto de permisos de los demás se los otorgaría mc.
Sin embargo, algo a tener en cuenta es que los permisos del propietario parecen prevalecer sobre todas las demás reglas de ACL, y creo que lo mismo ocurre con los permisos del propietario del grupo.
Arch Wiki tiene más información sobre las ACL. Verificarhttps://wiki.archlinux.org/title/Access_Control_Listssi está interesado en aprender más sobre ellos.
Es comprensible que no quieras comprobar siempre getfaclsi ese es tu problema o que te olvides de hacerlo. Afortunadamente, ls -alle indica cuándo se aplican reglas ACL adicionales. Si observa el resultado de ls -al, puede ver +al final de la lista de bits de permiso cada vez que se aplican reglas de ACL, y no muestra lo contrario (al menos ese parece ser el caso en mis breves pruebas). .
TLDR: si ve un +en la lista de permisos de ls -al, consulte la Lista de control de acceso ( getfacl).