Estou usando um Chromebook e gostaria de navegar dentro do contêiner do Android por meio do shell. O contêiner é montado no caminho /run/containers/android_XXXXX. Ao tentar cdentrar no diretório, me disseram Permission Denied. Tentei executar o comando como sudo, mas por algum motivo o cdcomando ficou inacessível. Corri chmod u+xno diretório, mas não há dados.
Que passos posso tomar a partir daqui?
Executei statno diretório, que retorna o seguinte:
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: -
Responder1
O diretório é drwx------para que apenas alguém cujo uid esteja 655350(que não esteja listado no arquivo de senha) possa lê-lo ou inseri-lo.
sudo cdnão ser capaz de encontrar o cdcomando é esperado, ele é um elemento interno do shell. Se não estivesse embutido, não funcionaria. Digamos que seu shell atual tenha um ID de processo 54000, você executou o comando /bin/cd, pode ser PID 54309. Ele mudaria o diretório do processo 54309 e sairia. o processo 54000 ainda estaria em seu diretório original.
chmod u+xaltera user (owner)a permissão.
O que você quer ésudo chmod go+rx /run/containers/android_XXXXX
Responder2
Além de verificar permissões como @icarus mencionado, você também precisa verificar suas ACLs (listas de controle de acesso) para getfaclter certeza de que não há regras que substituam os privilégios básicos de acesso a arquivos.
NOTA: Se getfaclnão existir no seu sistema, provavelmente não é o problema.
Exemplo de ACL que não deve ser um problema.
$ getfacl test/
# file: test/
# owner: root
# group: root
user::rwx
group::r-x
other::r-x
Isso indica que não há regras ACL adicionais aplicadas, além das regras de acesso POSIX padrão. Você pode ver que corresponde à saída ls -aldem termos de permissões. (O -dargumento to lsdiz para mostrar o diretório em si, não seu conteúdo.)
$ ls -ald test/
drwxr-xr-x 2 root root 4096 May 8 19:11 test/
Exemplo de uma ACL que pode causar 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/
Nesse caso, olhando para a saída de ls -ald, você não pensaria que haveria um problema. No entanto, como as regras ACL se aplicam às regras POSIX, o usuário mcnão poderá mudar para o diretório devido à falta de permissões executáveis para ele, apesar do fato de que o conjunto de permissões de outros as concederia a mc.
Algo a ser observado, porém, as permissões do proprietário parecem assumir a presidência de todas as outras regras da ACL, e acredito que o mesmo se aplica às permissões do proprietário do grupo.
O Arch Wiki tem mais informações sobre ACLs. Confirahttps://wiki.archlinux.org/title/Access_Control_Listsse você estiver interessado em aprender mais sobre eles.
Compreensivelmente, você pode não querer verificar sempre getfaclse esse é o seu problema ou pode esquecer de fazê-lo. Felizmente, ls -alele informa quando há regras adicionais de ACL aplicadas. Se você der uma olhada na saída de ls -al, poderá ver um +no final da lista de bits de permissão sempre que houver regras de ACL aplicadas, e não mostra o contrário (pelo menos esse parece ser o caso em meus breves testes) .
TLDR: Se você vir um +na lista de permissões de ls -al, verifique a Lista de Controle de Acesso ( getfacl).