Mecanismo de permissão de arquivos em sistemas semelhantes ao Unix

0

Alguém pode explicar com um exemplo o mecanismo de permissão de arquivo no Linux e outros sistemas semelhantes ao Unix? Quais são os nove bits para? Por que temos um ID de grupo para um usuário e também para um arquivo? Esses dois estão relacionados?

    
por Geek 07.12.2012 / 09:32

1 resposta

2

As permissões de propriedade e acesso funcionam basicamente em conjunto. A propriedade informa ao sistema quem pode acessar o arquivo, as permissões de arquivo dizem como .

Propriedade divide o acesso em três grupos: usuário (um único usuário que possui o arquivo), grupo (de usuários), outros (o resto do mundo).

As permissões são: r - a leitura é permitida, w - a escrita é permitida, x - a execução é permitida

Para diretórios, o significado é um pouco diferente: x permite que você insira um diretório, enquanto r lista seu conteúdo (e w permite atualizá-lo) - isso significa que, se você souber o nome exato do arquivo você não precisa de permissões de leitura no diretório em que reside, x é suficiente. Você precisa de r no arquivo.

Depois, há uma tripla de bit adicional: setuid, setgid, sticky. As duas primeiras causas (em um arquivo executável) o programa a ser executado como o usuário / grupo que possui o arquivo (dependendo de qual dos dois bits estão definidos). O bit pegajoso é dependente da implementação. Para executáveis, significava que o código do programa deveria ser armazenado em cache na troca para acelerar o carregamento da próxima vez. Para o diretório, evita que usuários sem privilégios removam um arquivo se não o possuírem, mesmo se tivessem o direito de fazê-lo de outra forma - é por isso que ele é geralmente configurado em diretórios graváveis do mundo, como /tmp .

Além disso, muitos sistemas de arquivos suportam listas de controle de acesso (ACL) adicionais que permitem um controle de acesso mais refinado. Estes são acessíveis com getfacl / setfacl em vez de chmod .

Como uma nota lateral, o sistema de permissão similar é geralmente implementado para memória (RAM) com granularidade da página. O principal objetivo é aderir ao princípio "W ^ X": ou você pode escrever na memória ou executá-la, mas não ambas ao mesmo tempo. Embora geralmente seja uma boa ideia, não funciona para código compilado just-in-time interpretado - por exemplo, Java, porque o interpretador precisa compilar / otimizar o código gerado (ou seja, para escrever a página) e, em seguida, executá-lo, muitas vezes de forma incremental (e alterando as permissões de cada vez não faria muito sentido).

    
por 07.12.2012 / 11:44