Em um sistema de arquivos do AFS, por que não consigo acessar alguns diretórios nos quais possuo permissões de rx e posso acessar alguns nos quais não tenho permissão?

Question

Encontrei algum comportamento inesperado ao tentar acessar diretórios em uma montagem do AFS usando o Linux (especificamente, no bash 4.3.11 (1) -release no Ubuntu 14.04.1). Em alguns casos, eu não consigo acessar diretórios que eu deveria ser capaz de acessar, e em outros eu sou capaz de acessar alguns diretórios onde eu não tenho permissão alguma. Por exemplo:

$ ls -l
total 24
drwxr-xr-x 9   70296     root     6144  Jan 12 14:44 look_inside
drwx------ 278 someadmin operator 10240 Jan 17 17:54 private
<output truncated>
$ cd look_inside
-bash: cd: look_inside: Permission denied
$ ls look_inside
ls: cannot open directory look_inside: Permission denied

Eu não sou o proprietário e não estou no grupo root , portanto, as permissões de todos devem se aplicar a look_inside. Todos têm r-x permissões para look_inside e todos os seus diretórios pai, mas não consigo usar cd look_inside ou ls look_inside . Por outro lado, eu posso acessar private , mesmo que eu não tenha permissões:

$ getfacl private
# file: private
# owner: cbl
# group: operator
user::rwx
group::---
other::---
$ ls -l private
total 560
<output truncated>

Eu também não sou o proprietário de private . Estou no grupo operator , mas isso não importa, pois o grupo não tem permissões para private . E, no entanto, consigo acessar privado. Dito isso, não consigo acessar nenhum diretório dentro dele, tenha ou não r-x permissões (veja abaixo). Isso faz sentido, é claro, porque eu não tenho x permissão para seus pais. Não há arquivos regulares em private (ou, pelo menos, apenas mostro diretórios quando executo ls ), então não sei como os arquivos regulares são afetados.

$ cd private
$ ls -l
total 560
drwx------ 3 someadmin  operator 2048 Jan 16 14:11 someuser
drwxr-xr-x 3 otheradmin operator 2048 Jan 16 14:11 otheruser
<output truncated>
$ ls -l someuser
ls: cannot open directory someuser: Permission denied
$ ls -l otheruser
ls: cannot open directory otheruser: Permission denied

O que poderia estar causando esse comportamento? Existe alguma maneira de acessar look_inside ? Devo eu (ou o administrador do sistema) estar ciente de que posso acessar private ?

    

Answer 1

O AFS não usa permissões tradicionais do Unix (embora ele se lembre delas), nem POSIX ACLs (o que você vê com getfacl ). Existem algumas exceções com permissões Unix (se você remover o acesso all para ler ou escrever com chmod , acredito que remove o acesso relevante para todos), mas de maneira geral o AFS usa seu próprio sistema ACL .

Supondo que você esteja usando o OpenAFS, para ver as permissões em um arquivo ou diretório, execute fs listacl <path> . Para definir as permissões, se você tiver acesso, execute fs setacl <path> <user> <perms> . As permissões concedidas pelas ACLs do AFS são diferentes das permissões no estilo chmod do Unix, ACLs POSIX e, bem, de qualquer outro sistema de acesso que eu saiba. Eles são explicados em detalhes aqui , mas resumidamente: você tem 7 permissões, geralmente representadas por uma única letra. Eles são: 'r'ead,' l'ist, w'rite, 'i'ert', d'elete, loc'k 'e' a'dmin.

Assim, por exemplo, um diretório que você pode ver e ler arquivos seria assim:

$ fs listacl somedir
Access list for somedir is
Normal rights:
   system:anyuser rl
   system:administrators rlidwka

O que significa que 'system: anyuser' (qualquer pessoa no mundo) pode apenas 'l' o conteúdo do diretório e 'r' o conteúdo dos arquivos nesse diretório. Por outro lado, 'system: administrators' (um grupo usado por usuários admin) pode fazer qualquer coisa.

Um diretório que você não pode acessar pode ter esta aparência:

$ fs listacl privdir
Access list for privdir is
Normal rights:
   system:administrators rlidwka
   foouser rlidwka

O que significa que apenas administradores e 'foouser' podem fazer qualquer coisa nesse diretório. No entanto, se você não conseguir acessar um diretório, acho que você também não poderá fs listacl , de modo que mostrará uma mensagem de erro.

Se você não estiver usando o OpenAFS, mas usando a implementação do AFS na árvore de código fonte do Linux upstream ("kAFS"), então você não terá o comando fs . Não acredito que seja possível visualizar as ACLs do AFS com essa implementação, mas posso estar errado sobre isso.

    

Answer 2

As listas de controle de acesso podem fazer isso. Você verificou seu nome de usuário e grupos na sessão de bash? whoami e groups