-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jaboatão dos Guararapes, PE, 02 de setembro de 2014.
Aqui está, em tradução livre para a língua portuguesa falada no Brasil, o texto postado por Perderabo "Permissões de Arquivos do Unix".
Unix File Permissions (Perderabo, 28/05/2005 - http://www.unix.com/tips-and-tutorials/19060-unix-file-permissions.html)
Introdução
Eu tenho visto alguma informação errada relativamente às permissões de arquivo do Unix. Eu tentarei esclarecer as coisas. Dá uma olhada neste exemplo de alguma saída do ls:
$ ls -ld /usr/bin /usr/bin/cat
drwxrwxr-x 3 root bin 8704 Sep 23 2004 /usr/bin
- -r-xr-xr-x 1 bin bin 9388 Jul 16 1997 /usr/bin/cat
$
Na primeira linha, aquele "root" diz que o diretório é propriedade do usuário chamado "root". E que "bin" ś o grupo do diretório. Você precisará entender usuários e grupos e eu presumirei que você entende. Meu objetivo é explicar aquelas "drwxrwxr-x" e "-r-xr-xr-x" coisas. Aquele campo é uma combinação do tipo do arquivo e permissão de acesso. Coletivamente, essa informação é algumas vezes chamada de modo do arquivo. E algumas vezes ela é chamada de permissões. Um bom lugar para começar é dando uma rápida olhada em como essa informação é atualmente armazenada no disco. A forma como ela é armazenada afeta um número de decisões que devem ser tomadas ao longo dos anos.
Como o "Modo do Arquivo" é armazenado.
No disco, informação acerca de um arquivo é armazenada em uma estrutura chamada um "inode". Cada arquivo tem o seu próprio inode. Um item de dados em um inode é chamado de "modo" e ele se parece com isto:
|---modo do arquivo---|
| |
|
| |--completo---|
|
|-tipo| | |-básico--|
| | | | |
oo0 000 000 000 000 000
... ... ... ... ... ...
| | | | |
| | | | |---- rwx para outros
| | | |
| | | |-------- rwx para grupo
| | |
| | |------------ rwx para usuário
| |
| |---------------- configura uid, configura gid, sticky bit
|
|---------------------- tipo do arquivo: comum (-)
diretório (d)
carácter especial (c)
bloco especial (b)
fifo (p)
ligação simbólica (l)
socket (s)
Eu entendo que o "modo" realmente significa simplesmente as permissões e que o tipo do arquivo foi enfiado para dentro para economizar espaço. Porém, o autor do aplicativo ls está tratando o modo como um item único. Eis o porque de o tipo do arquivo ser o primeiro carácter da sequência de permissão no saída de "ls -l". O tipo do arquivo usualmente será um dos sete tipos que eu mostrei acima. Algumas versões de Unix adicionarão alguns mais. A única outra coisa a saber a partir do formato é que não existe mais compartimento para adicionar mais bits de permissão.
Representando aquelas permissões em octal
O aplicativo ls pode exibir, digamos, "rwxrwxrwx" para as permissões em um arquivo. Também é muito comum utilizar um número octal para expressar as permissões em um arquivo. E como você vê acima, assim é como elas são armazenadas. Você pode escutar alguém dizer que alguns tem permissões 777. Isso é o mesmo que "rwxrwxrwx" e muito mais fácil de pronunciar. Então você precisa saber como convertê-los. Três dígitos binários ou bits correspondem a um dígito octal:
421
rwx
Assim, o bit de leitura tem valor 4, o bit de escrita tem valor 2, e o bit de execução tem valor 1. Você simplesmente adiciona tais valores para obter um dígito octal. Então, "-rwxrwxrwx" é 777. E "-rwxr-x---" é 750. Se você ainda não consegue ver como ir de "r-x" para 5, talvez esta tabela ajude:
- --- = 0
- --x = 1
- -w- = 2
- -wx = 3
r-- = 4
r-x = 5
rw- = 6
rwx = 7
Perceba que precisamos de 4 dígitos octais para exprimir todos os bits de permissões. Os primeiros três bits são especiais e são frequentemente zero. E você quase sempre aprende primeiro sobre os 9 bits seguintes. Algumas pessoas param aí e nunca aprendem aqueles primeiros três bits. Porém, existem 12 bits de permissão, não apenas 9. Dito isso, vamos agora dar uma olhada nos 9 bits seguintes.
Os Bits de Permissão Básicos
Nós temos 3 triplas: uma tripla para o usuário, uma tripla para o grupo, e uma tripla para outros. Algumas vezes o "usuário" é chamado de proprietário. E algumas vezes "outros" é chamado de "mundo" Eu utilizarei "usuário" e "outros" pois o comando chmod utiliza as letras "u", "g" e "o" para se referir àquelas triplas.
Qual Conjunto de Bits Aplica-se a Você?
Quando Unix decide o que você pode fazer, ele não utiliza todos os 9 bits. Unix pega a primeira tripla que aplica-se a você. Considere isto:
- ----rwxrwx 1 joe users 29 Mar 22 19:39 algumarquivo
Mesmo que joe seja dono desse arquivo, ele não pode acessá-lo. (Uma vez que joe é dono do arquivo, ele poderia dar acesso a ele próprio. Mais sobre isso depois). Também root é especial. A root é permitido rwx a todos os diretórios e rw a todos os arquivos. Em um arquivo, se quaisquer dos 3 bits estiverem configurados, root tem permissão de execução. Essa permissão especial é frequentemente desabilitada em sistemas de arquivos montados via rede.
O que "r", "w" e "x" realmente significam para um arquivo?
Para um arquivo, "read" [leitura] e "write" [escrita] são bastante intuitivos. O "x" para "execução" significa que o kernel pode tentar executar um arquivo. Para que isso funcione, o arquivo deve ser um executável (saída de um compilador) ou um script de shell com um "#!" na primeira linha. Para um diretório, as coisas são um pouco mais complexas. Com um diretório, a permissão "write" [escrita] significa que você pode criar novos arquivos em um diretório ou remover arquivos antigos. Ela as vezes surpreende as pessoas pois você pode remover um arquivo o qual você não pode ler. O comando rm do Unix testará tal situação e emitirá um alerta, porém você pode suprimir tal alerta com -f. E alertando ou não, se você deseja remover um arquivo ilegível de um diretório gravável, você pode. E rmdir não se preocupará em verificar de jeito nenhum.
O que "r", "w" e "x" realmente significam para um diretório?
Um diretório é um arquivo também, e a permissão "read" significa que você pode lê-lo. Porém você realmente não pode fazer muita coisa sem a permissão "x" também. Com diretórios, você usualmente tem ambas as permissões leitura e execução ou nenhuma. Em um diretório, aquele "x" é oficialmente chamado "permissão de busca". Você precisa de um "x" para utilizar um diretório em uma localização. Assim, se você tentar "cat /etc/passwd", você precisará do "x" em / e /etc. Você também precisa "x" para acessar o diretório com um cd. Suponha que você tenha permissão de leitura, mas não de busca (x) em um diretório. O que você pode fazer? Não muito. Você pode utilizar "ls" para visualizar os nomes de arquivos. Mesmo "ls -l" não funcionará. Acesso de leitura sem permissão de busca não é realmente útil. Ainda é melhor do que ter apenas permissão de escrita em um diretório... isso é completamente inútil. Eu não tenho visto qualquer outra documentação que declare isso explicitamente, de forma que permita-me repetir: escrita mas sem permissão de execução em um diretório não concede nada para ninguém. Suponha que você tenha permissão de busca (x), mas não permissão de leitura em um diretório. Agora você pode abrir arquivos em um diretório se acontecer de você saber o nome do arquivo. Você pode acessar o diretório [com cd]. E isso é tudo. Você não pode nem mesmo criar um arquivo novo. Adicionar permissão de escrita permitirá a você criar arquivos. E você pode então apagar arquivos se acontecer de você saber o nome deles.
Ligações Simbólicas São Especiais
As configurações de permissão em uma ligação simbólica são um pouco especiais também. Elas são completamente ignoradas. Muitas versões de Unix não tem um meio de mudá-las.
Os Bits Setuid e Setgid
Dá uma olhada nisto:
$ ls -l /etc/passwd /etc/shadow /usr/bin/passwd
- -r--r--r-- 1 root sys 14006 Jan 14 11:17 /etc/passwd
- -r-------- 1 root sys 8281 Jan 14 11:18 /etc/shadow
- -r-sr-sr-x 3 root sys 96244 Sep 5 2001 /usr/bin/passwd
O arquivo passwd é gravável apenas pelo root (lembre-se, root é especial. Ele pode gravar um arquivo que não tem permissões de escrita configuradas). O arquivo shadow, no qual senhas são armazenas, não pode nem mesmo ser lido por usuários comuns. Porém, joe deseja mudar a senha dele. Ele pode fazer isso executando /usr/bin/passwd. Perceba aquelas permissões r-s. O aplicativo passwd tem os bits suid e sgid configurados. Isso transforma os "x" em "s". Em octal, seria 6555. O aplicativo passwd é de propriedade do root. Quando joe o executa, ele não é executado como "joe". Ao invés disso, é executado como seu usuário que é o root. Assim, o aplicativo passwd pode mudar a senha de joe para ele. O bit sgid funciona da mesma maneira, exceto que ele faz com que o aplicativo passwd seja executado como grupo sys ao invés do grupo do joe. O suid e sgid não tem suas próprias posições no ls. Quando o bit suid está configurado, ls exibe um "s" no lugar de um "x" para a permissão de execução do proprietário. O que acontece se o bit suid estiver configurado, porém o bit de execução do proprietário estiver desligado? ls exibirá um "S" maiúsculo no caso. O bit sgid é exibido de uma maneira singular, exceto que ele interage com a permissão de execução do grupo. (O conceito do conjunto uid foi inventado por Dennis Ritchie quando ele estava desenvolvendo Unix).
Para expandir as coisas um pouco, enquanto que jos está executando o aplicativo suid-para-root passwd, "joe" é o uid real e "root" é o uid efetivo. O aplicativo passwd pode obter ambas dessas id's se ele desejar fazê-lo. Assim é como o aplicativo passwd sabe como permitir a joe mudar apenas a senha de joe.
O Bit Sticky
O padrão Posix diz que se o bit sticky estiver configurado para um diretório, a simples permissão de escrita no diretório não mais é suficiente para permitir que arquivos sejam removidos. Você deve adicionalmente ser dono do arquivo ou ser dono do diretório. root permanece sendo hábil para apagar de qualquer diretório independentemente das permissões. Antigamente esse bit servia a um outro propósito. Em alguns Sistemas Operacionais ele ainda serve. Eu completarei em um apêndice abaixo. O bit sticky afeta o bit de execução "outros" na exibição ls. Exceto pelo fato de que ele utiliza "t" e "T" no lugar de "s" e "S". Por exemplo:
drwxrwxrwt 5 root root 1024 Feb 11 20:43 /tmp
Naquele diretório /tmp acima, qualquer pessoa pode criar novos arquivos. Porém, por causa do bit sticky, um usuário não pode apagar os arquivos de um outro usuário.
Limitando Permissões de Arquivo com umask
Quando arquivos são criados, o aplicativo que os cria pode especificar a configuração inicial de permissão. Você pode sobrescrever isso com umask. O umask é um conjunto de bits de proibição. Existe um comando umask que te permite visualizar e mudar o umask. Por exemplo, "umask 022" proíbe escrita de grupo e escrita de outros em arquivos recém criados. Ou "umask 027" proíbe escrita de grupo e proíbe leitura, escrita e execução de outros. Você pode executar um "umask 0" para permitir que o aplicativo faça o que ele desejar a medida que ele cria aplicativos. Porém, você não pode ir mais além. Você não pode forçar um aplicativo a ligar um bit. A configuração de umask afeta arquivos, diretórios, pipes nomeados (também conhecidos como fifos), e arquivos especiais. Ele pode ou não pode afetar ligações simbólicas. Ele também afeta algumas formas de Comunicação Inter Processos (Inter Process Communication), mas isso está além do escopo deste artigo. E, acredite se quiser, sockets nomeados são imunes a umask. Essa imunidade é exigida por Posix.
Mudando Permissões de Arquivos com chmod
Apenas o proprietário de um arquivo pode mudar as permissões sobre um arquivo. Essa operação não é afetada de nenhuma maneira pela configuração de umask. Se você mudar as permissões sobre uma ligação simbólica, a ligação será seguida e você mudará o arquivo alvo. É possível que apenas o root tenha o poder de configurar um bit sticky de um arquivo. Como um exemplo, "chmod 700 algumarquivo" permitirá que o proprietário leia, escreva e execute o arquivo, enquanto que proíbe todo acesso a quaisquer outros usuários.
Utilizando Modo Simbólico com chmod e umask
Posix introduziu uma nova sintaxe para o comando chmod. A ideia foi que a nova sintaxe substituirá o uso de uma constante octal com o comando chmod. A constante octal ainda é válida e eu entendo que ela chegou para ficar. Porém, a nova sintaxe simbólica te permite mudar uns poucos bits sem o conhecimento do que os outros são. Por exemplo, digamos que eu deseje tornar um arquivo inacessível para outros, mas eu não desejo mudar o acesso para o usuário ou o grupo. Eu precisaria fazer:
ls -l arquivo
Olhar para o arquivo e descobrir as configurações atuais.
chmod 750 arquivo
Eu tive de determinar que os primeiros dois dígitos são atuais 7 e 5 antes que podesse executar meu comando chmod. Com a nova sintaxe, eu posso simplesmente fazer:
chmod o= arquivo
para desligar os 3 bits finais. Como um outro exemplo, "chmod u+x file" permitirá que o usuário execute o arquivo. Por outro lado, esses dois comandos são equivalentes:
chmod 750 arquivo
chmod u=rwx,g=rx,o= arquivo
e eu prefiro a primeira sintaxe.
O modo simbólico pode ser uma lista de especificações separada por vírgulas. Cada especificação tem três componentes: <quem><operação><bitlist>
A parte quem pode ser:
u (usuário)
g (grupo)
o (outros)
a (all - todos)
(o que seja permitido por umask (subconjunto de tudo))
A operação pode ser = ou - ou +
= (configura para bitlist)
- - (subtrai bitlist do bit atual
+ (adiciona bitllist aos bits atuais)
A bitlist pode ser uma das seguintes letras:
r (permissão de leitura - read)
w (permissão de escrita - write)
x (permissão de execução - execute)
X (permissão condicional de execução)
u (permissões atuais para o usuário)
g (permissões atuais para o grupo)
o (permissões atuais para outros)
s (configura uid ou configura gid)
t (sticky bit)
O "X" é o mesmo que "x" a menos que o arquivo seja um não-diretório e atualmente não tenha bits "x" configurados. O "s" (configura uid ou configura gid) pode apenas ser especificado para permissões de usuário ou de grupo. O "t" pode apenas ser especificado para permissões de usuário. Uns poucos exemplos com ajuda. Acima nós vimos que /usr/bin/passwd tinha 6555 (-r-sr-sr-x no ls). Aqui estão alguns caminhos para que aquilo seja alcançado:
chmod 6555 /usr/bin/passwd
chmod u=rxs,g=rxs,o=rx /usr/bin/passwd
chmod ug=rxs,o=rx /usr/bin/passwd
chmod a=rx,ug+s /usr/bin/passwd
E existem muitas outras maneiras de se fazer isso.
Para a maior parte, chmod é imune a umask em quaisquer daqueles bits que ele deseje configurar, não seja modificado por umask. Entretanto, sob uma condição, o comando chmod examinará a configuração atual de umask para determinar quais bits ele gostaria de configurar. Isso acontece quando você deixa o campo "quem" em branco. Como isso:
chmod =w algumarquivo
A diferença entre "a=w" and "=w" é sútil. Aqui está um exemplo que pode ajudar. Muitos aplicativos tentam criar arquivo com permissões 666 (-rw-rw-rw-). Porém, isso é modificado pelo umask. Suponha que você deseja configurar um arquivo para 666, porém modificado pelo umask atual. Nós poderíamos desligar todos os bits, então ligar os bits de leitura e escrita permitidos pelo umask atual:
chmod a=,=rw algumarquivo
E falando em umask, você pode utilizar argumentos simbólicos com o comando umask também. Entretanto, Posix, em sua sabedoria, decidiu que, nesse caso, a lógica seria reversa. Assim, se utilizar umask com um argumento octal, você especifica que os bits sejam proibidos. Porém, se você utiliza umask com um argumento simbólico, você especifica que os bits sejam permitidos. Então, esses são equivalentes:
umask 022
umask u=rwx,go=rx
Sumário
Neste ponto, você tem informação suficiente para entender a maior parte daqueles 12 bits de permissão. Existem vários casos especiais que eu ignorei ou camuflei. Nas postagens separadas abaixo, eu tratarei desses. A informação nesta primeira postagem é bastante universal. Um OS compatível com Posix deve suportar essas coisas. Isso cobre quase todas as versões de Unix lançadas nos últimos 10 anos. Os artigos seguintes discutem características que podem não serem universais.
Disponível em: <http://www.unix.com/tips-and-tutorials/19060-unix-file-permissions.html>. Acesso em: 01 set. 2014.
Jamenson Ferreira Espindula de Almeida Melo
Linux user nº 166197
https://linuxcounter.net/cert/166197.png
Impressão digital da chave:
234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBAgAGBQJUBUtuAAoJECrgJcAIqGGAOSQIAILUDlkx0XJivgUEOh0newTr
DTxTWOOnHR2bf1NWUWWRzrFi/i3LJFH96IMOqfsSCQ5q/wopm4iN9Dvz5pnDd9nY
F24IJrSwiLQWQRSzmldRsCFaSfPth7s2cKMLdTYEIXkGCUmwFCnGDY43OCsoQVYC
Qz3sPXORXQCk3dsOvAJbJ75Zn3GeHa0LTRVLuQdn2slu3TvqyVXih5JqxkmHD0ld
D6ZtQBYfvk6z7Xug6GZFA52j7i8kZw+XBk3YgQuLTYpP8EkZlDsUDby/3SylDawU
6jpfTbU7c1es8EPqmEAjL/iC4LM9qJrnRcuTDqQyYCG5du+Y9UoBsm+FBros4Do=
=Gpfr
-----END PGP SIGNATURE-----
Hash: SHA1
Jaboatão dos Guararapes, PE, 02 de setembro de 2014.
Aqui está, em tradução livre para a língua portuguesa falada no Brasil, o texto postado por Perderabo "Permissões de Arquivos do Unix".
Unix File Permissions (Perderabo, 28/05/2005 - http://www.unix.com/tips-and-tutorials/19060-unix-file-permissions.html)
Introdução
Eu tenho visto alguma informação errada relativamente às permissões de arquivo do Unix. Eu tentarei esclarecer as coisas. Dá uma olhada neste exemplo de alguma saída do ls:
$ ls -ld /usr/bin /usr/bin/cat
drwxrwxr-x 3 root bin 8704 Sep 23 2004 /usr/bin
- -r-xr-xr-x 1 bin bin 9388 Jul 16 1997 /usr/bin/cat
$
Na primeira linha, aquele "root" diz que o diretório é propriedade do usuário chamado "root". E que "bin" ś o grupo do diretório. Você precisará entender usuários e grupos e eu presumirei que você entende. Meu objetivo é explicar aquelas "drwxrwxr-x" e "-r-xr-xr-x" coisas. Aquele campo é uma combinação do tipo do arquivo e permissão de acesso. Coletivamente, essa informação é algumas vezes chamada de modo do arquivo. E algumas vezes ela é chamada de permissões. Um bom lugar para começar é dando uma rápida olhada em como essa informação é atualmente armazenada no disco. A forma como ela é armazenada afeta um número de decisões que devem ser tomadas ao longo dos anos.
Como o "Modo do Arquivo" é armazenado.
No disco, informação acerca de um arquivo é armazenada em uma estrutura chamada um "inode". Cada arquivo tem o seu próprio inode. Um item de dados em um inode é chamado de "modo" e ele se parece com isto:
|---modo do arquivo---|
| |
|
| |--completo---|
|
|-tipo| | |-básico--|
| | | | |
oo0 000 000 000 000 000
... ... ... ... ... ...
| | | | |
| | | | |---- rwx para outros
| | | |
| | | |-------- rwx para grupo
| | |
| | |------------ rwx para usuário
| |
| |---------------- configura uid, configura gid, sticky bit
|
|---------------------- tipo do arquivo: comum (-)
diretório (d)
carácter especial (c)
bloco especial (b)
fifo (p)
ligação simbólica (l)
socket (s)
Eu entendo que o "modo" realmente significa simplesmente as permissões e que o tipo do arquivo foi enfiado para dentro para economizar espaço. Porém, o autor do aplicativo ls está tratando o modo como um item único. Eis o porque de o tipo do arquivo ser o primeiro carácter da sequência de permissão no saída de "ls -l". O tipo do arquivo usualmente será um dos sete tipos que eu mostrei acima. Algumas versões de Unix adicionarão alguns mais. A única outra coisa a saber a partir do formato é que não existe mais compartimento para adicionar mais bits de permissão.
Representando aquelas permissões em octal
O aplicativo ls pode exibir, digamos, "rwxrwxrwx" para as permissões em um arquivo. Também é muito comum utilizar um número octal para expressar as permissões em um arquivo. E como você vê acima, assim é como elas são armazenadas. Você pode escutar alguém dizer que alguns tem permissões 777. Isso é o mesmo que "rwxrwxrwx" e muito mais fácil de pronunciar. Então você precisa saber como convertê-los. Três dígitos binários ou bits correspondem a um dígito octal:
421
rwx
Assim, o bit de leitura tem valor 4, o bit de escrita tem valor 2, e o bit de execução tem valor 1. Você simplesmente adiciona tais valores para obter um dígito octal. Então, "-rwxrwxrwx" é 777. E "-rwxr-x---" é 750. Se você ainda não consegue ver como ir de "r-x" para 5, talvez esta tabela ajude:
- --- = 0
- --x = 1
- -w- = 2
- -wx = 3
r-- = 4
r-x = 5
rw- = 6
rwx = 7
Perceba que precisamos de 4 dígitos octais para exprimir todos os bits de permissões. Os primeiros três bits são especiais e são frequentemente zero. E você quase sempre aprende primeiro sobre os 9 bits seguintes. Algumas pessoas param aí e nunca aprendem aqueles primeiros três bits. Porém, existem 12 bits de permissão, não apenas 9. Dito isso, vamos agora dar uma olhada nos 9 bits seguintes.
Os Bits de Permissão Básicos
Nós temos 3 triplas: uma tripla para o usuário, uma tripla para o grupo, e uma tripla para outros. Algumas vezes o "usuário" é chamado de proprietário. E algumas vezes "outros" é chamado de "mundo" Eu utilizarei "usuário" e "outros" pois o comando chmod utiliza as letras "u", "g" e "o" para se referir àquelas triplas.
Qual Conjunto de Bits Aplica-se a Você?
Quando Unix decide o que você pode fazer, ele não utiliza todos os 9 bits. Unix pega a primeira tripla que aplica-se a você. Considere isto:
- ----rwxrwx 1 joe users 29 Mar 22 19:39 algumarquivo
Mesmo que joe seja dono desse arquivo, ele não pode acessá-lo. (Uma vez que joe é dono do arquivo, ele poderia dar acesso a ele próprio. Mais sobre isso depois). Também root é especial. A root é permitido rwx a todos os diretórios e rw a todos os arquivos. Em um arquivo, se quaisquer dos 3 bits estiverem configurados, root tem permissão de execução. Essa permissão especial é frequentemente desabilitada em sistemas de arquivos montados via rede.
O que "r", "w" e "x" realmente significam para um arquivo?
Para um arquivo, "read" [leitura] e "write" [escrita] são bastante intuitivos. O "x" para "execução" significa que o kernel pode tentar executar um arquivo. Para que isso funcione, o arquivo deve ser um executável (saída de um compilador) ou um script de shell com um "#!" na primeira linha. Para um diretório, as coisas são um pouco mais complexas. Com um diretório, a permissão "write" [escrita] significa que você pode criar novos arquivos em um diretório ou remover arquivos antigos. Ela as vezes surpreende as pessoas pois você pode remover um arquivo o qual você não pode ler. O comando rm do Unix testará tal situação e emitirá um alerta, porém você pode suprimir tal alerta com -f. E alertando ou não, se você deseja remover um arquivo ilegível de um diretório gravável, você pode. E rmdir não se preocupará em verificar de jeito nenhum.
O que "r", "w" e "x" realmente significam para um diretório?
Um diretório é um arquivo também, e a permissão "read" significa que você pode lê-lo. Porém você realmente não pode fazer muita coisa sem a permissão "x" também. Com diretórios, você usualmente tem ambas as permissões leitura e execução ou nenhuma. Em um diretório, aquele "x" é oficialmente chamado "permissão de busca". Você precisa de um "x" para utilizar um diretório em uma localização. Assim, se você tentar "cat /etc/passwd", você precisará do "x" em / e /etc. Você também precisa "x" para acessar o diretório com um cd. Suponha que você tenha permissão de leitura, mas não de busca (x) em um diretório. O que você pode fazer? Não muito. Você pode utilizar "ls" para visualizar os nomes de arquivos. Mesmo "ls -l" não funcionará. Acesso de leitura sem permissão de busca não é realmente útil. Ainda é melhor do que ter apenas permissão de escrita em um diretório... isso é completamente inútil. Eu não tenho visto qualquer outra documentação que declare isso explicitamente, de forma que permita-me repetir: escrita mas sem permissão de execução em um diretório não concede nada para ninguém. Suponha que você tenha permissão de busca (x), mas não permissão de leitura em um diretório. Agora você pode abrir arquivos em um diretório se acontecer de você saber o nome do arquivo. Você pode acessar o diretório [com cd]. E isso é tudo. Você não pode nem mesmo criar um arquivo novo. Adicionar permissão de escrita permitirá a você criar arquivos. E você pode então apagar arquivos se acontecer de você saber o nome deles.
Ligações Simbólicas São Especiais
As configurações de permissão em uma ligação simbólica são um pouco especiais também. Elas são completamente ignoradas. Muitas versões de Unix não tem um meio de mudá-las.
Os Bits Setuid e Setgid
Dá uma olhada nisto:
$ ls -l /etc/passwd /etc/shadow /usr/bin/passwd
- -r--r--r-- 1 root sys 14006 Jan 14 11:17 /etc/passwd
- -r-------- 1 root sys 8281 Jan 14 11:18 /etc/shadow
- -r-sr-sr-x 3 root sys 96244 Sep 5 2001 /usr/bin/passwd
O arquivo passwd é gravável apenas pelo root (lembre-se, root é especial. Ele pode gravar um arquivo que não tem permissões de escrita configuradas). O arquivo shadow, no qual senhas são armazenas, não pode nem mesmo ser lido por usuários comuns. Porém, joe deseja mudar a senha dele. Ele pode fazer isso executando /usr/bin/passwd. Perceba aquelas permissões r-s. O aplicativo passwd tem os bits suid e sgid configurados. Isso transforma os "x" em "s". Em octal, seria 6555. O aplicativo passwd é de propriedade do root. Quando joe o executa, ele não é executado como "joe". Ao invés disso, é executado como seu usuário que é o root. Assim, o aplicativo passwd pode mudar a senha de joe para ele. O bit sgid funciona da mesma maneira, exceto que ele faz com que o aplicativo passwd seja executado como grupo sys ao invés do grupo do joe. O suid e sgid não tem suas próprias posições no ls. Quando o bit suid está configurado, ls exibe um "s" no lugar de um "x" para a permissão de execução do proprietário. O que acontece se o bit suid estiver configurado, porém o bit de execução do proprietário estiver desligado? ls exibirá um "S" maiúsculo no caso. O bit sgid é exibido de uma maneira singular, exceto que ele interage com a permissão de execução do grupo. (O conceito do conjunto uid foi inventado por Dennis Ritchie quando ele estava desenvolvendo Unix).
Para expandir as coisas um pouco, enquanto que jos está executando o aplicativo suid-para-root passwd, "joe" é o uid real e "root" é o uid efetivo. O aplicativo passwd pode obter ambas dessas id's se ele desejar fazê-lo. Assim é como o aplicativo passwd sabe como permitir a joe mudar apenas a senha de joe.
O Bit Sticky
O padrão Posix diz que se o bit sticky estiver configurado para um diretório, a simples permissão de escrita no diretório não mais é suficiente para permitir que arquivos sejam removidos. Você deve adicionalmente ser dono do arquivo ou ser dono do diretório. root permanece sendo hábil para apagar de qualquer diretório independentemente das permissões. Antigamente esse bit servia a um outro propósito. Em alguns Sistemas Operacionais ele ainda serve. Eu completarei em um apêndice abaixo. O bit sticky afeta o bit de execução "outros" na exibição ls. Exceto pelo fato de que ele utiliza "t" e "T" no lugar de "s" e "S". Por exemplo:
drwxrwxrwt 5 root root 1024 Feb 11 20:43 /tmp
Naquele diretório /tmp acima, qualquer pessoa pode criar novos arquivos. Porém, por causa do bit sticky, um usuário não pode apagar os arquivos de um outro usuário.
Limitando Permissões de Arquivo com umask
Quando arquivos são criados, o aplicativo que os cria pode especificar a configuração inicial de permissão. Você pode sobrescrever isso com umask. O umask é um conjunto de bits de proibição. Existe um comando umask que te permite visualizar e mudar o umask. Por exemplo, "umask 022" proíbe escrita de grupo e escrita de outros em arquivos recém criados. Ou "umask 027" proíbe escrita de grupo e proíbe leitura, escrita e execução de outros. Você pode executar um "umask 0" para permitir que o aplicativo faça o que ele desejar a medida que ele cria aplicativos. Porém, você não pode ir mais além. Você não pode forçar um aplicativo a ligar um bit. A configuração de umask afeta arquivos, diretórios, pipes nomeados (também conhecidos como fifos), e arquivos especiais. Ele pode ou não pode afetar ligações simbólicas. Ele também afeta algumas formas de Comunicação Inter Processos (Inter Process Communication), mas isso está além do escopo deste artigo. E, acredite se quiser, sockets nomeados são imunes a umask. Essa imunidade é exigida por Posix.
Mudando Permissões de Arquivos com chmod
Apenas o proprietário de um arquivo pode mudar as permissões sobre um arquivo. Essa operação não é afetada de nenhuma maneira pela configuração de umask. Se você mudar as permissões sobre uma ligação simbólica, a ligação será seguida e você mudará o arquivo alvo. É possível que apenas o root tenha o poder de configurar um bit sticky de um arquivo. Como um exemplo, "chmod 700 algumarquivo" permitirá que o proprietário leia, escreva e execute o arquivo, enquanto que proíbe todo acesso a quaisquer outros usuários.
Utilizando Modo Simbólico com chmod e umask
Posix introduziu uma nova sintaxe para o comando chmod. A ideia foi que a nova sintaxe substituirá o uso de uma constante octal com o comando chmod. A constante octal ainda é válida e eu entendo que ela chegou para ficar. Porém, a nova sintaxe simbólica te permite mudar uns poucos bits sem o conhecimento do que os outros são. Por exemplo, digamos que eu deseje tornar um arquivo inacessível para outros, mas eu não desejo mudar o acesso para o usuário ou o grupo. Eu precisaria fazer:
ls -l arquivo
Olhar para o arquivo e descobrir as configurações atuais.
chmod 750 arquivo
Eu tive de determinar que os primeiros dois dígitos são atuais 7 e 5 antes que podesse executar meu comando chmod. Com a nova sintaxe, eu posso simplesmente fazer:
chmod o= arquivo
para desligar os 3 bits finais. Como um outro exemplo, "chmod u+x file" permitirá que o usuário execute o arquivo. Por outro lado, esses dois comandos são equivalentes:
chmod 750 arquivo
chmod u=rwx,g=rx,o= arquivo
e eu prefiro a primeira sintaxe.
O modo simbólico pode ser uma lista de especificações separada por vírgulas. Cada especificação tem três componentes: <quem><operação><bitlist>
A parte quem pode ser:
u (usuário)
g (grupo)
o (outros)
a (all - todos)
(o que seja permitido por umask (subconjunto de tudo))
A operação pode ser = ou - ou +
= (configura para bitlist)
- - (subtrai bitlist do bit atual
+ (adiciona bitllist aos bits atuais)
A bitlist pode ser uma das seguintes letras:
r (permissão de leitura - read)
w (permissão de escrita - write)
x (permissão de execução - execute)
X (permissão condicional de execução)
u (permissões atuais para o usuário)
g (permissões atuais para o grupo)
o (permissões atuais para outros)
s (configura uid ou configura gid)
t (sticky bit)
O "X" é o mesmo que "x" a menos que o arquivo seja um não-diretório e atualmente não tenha bits "x" configurados. O "s" (configura uid ou configura gid) pode apenas ser especificado para permissões de usuário ou de grupo. O "t" pode apenas ser especificado para permissões de usuário. Uns poucos exemplos com ajuda. Acima nós vimos que /usr/bin/passwd tinha 6555 (-r-sr-sr-x no ls). Aqui estão alguns caminhos para que aquilo seja alcançado:
chmod 6555 /usr/bin/passwd
chmod u=rxs,g=rxs,o=rx /usr/bin/passwd
chmod ug=rxs,o=rx /usr/bin/passwd
chmod a=rx,ug+s /usr/bin/passwd
E existem muitas outras maneiras de se fazer isso.
Para a maior parte, chmod é imune a umask em quaisquer daqueles bits que ele deseje configurar, não seja modificado por umask. Entretanto, sob uma condição, o comando chmod examinará a configuração atual de umask para determinar quais bits ele gostaria de configurar. Isso acontece quando você deixa o campo "quem" em branco. Como isso:
chmod =w algumarquivo
A diferença entre "a=w" and "=w" é sútil. Aqui está um exemplo que pode ajudar. Muitos aplicativos tentam criar arquivo com permissões 666 (-rw-rw-rw-). Porém, isso é modificado pelo umask. Suponha que você deseja configurar um arquivo para 666, porém modificado pelo umask atual. Nós poderíamos desligar todos os bits, então ligar os bits de leitura e escrita permitidos pelo umask atual:
chmod a=,=rw algumarquivo
E falando em umask, você pode utilizar argumentos simbólicos com o comando umask também. Entretanto, Posix, em sua sabedoria, decidiu que, nesse caso, a lógica seria reversa. Assim, se utilizar umask com um argumento octal, você especifica que os bits sejam proibidos. Porém, se você utiliza umask com um argumento simbólico, você especifica que os bits sejam permitidos. Então, esses são equivalentes:
umask 022
umask u=rwx,go=rx
Sumário
Neste ponto, você tem informação suficiente para entender a maior parte daqueles 12 bits de permissão. Existem vários casos especiais que eu ignorei ou camuflei. Nas postagens separadas abaixo, eu tratarei desses. A informação nesta primeira postagem é bastante universal. Um OS compatível com Posix deve suportar essas coisas. Isso cobre quase todas as versões de Unix lançadas nos últimos 10 anos. Os artigos seguintes discutem características que podem não serem universais.
Disponível em: <http://www.unix.com/tips-and-tutorials/19060-unix-file-permissions.html>. Acesso em: 01 set. 2014.
Jamenson Ferreira Espindula de Almeida Melo
Linux user nº 166197
https://linuxcounter.net/cert/166197.png
Impressão digital da chave:
234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBAgAGBQJUBUtuAAoJECrgJcAIqGGAOSQIAILUDlkx0XJivgUEOh0newTr
DTxTWOOnHR2bf1NWUWWRzrFi/i3LJFH96IMOqfsSCQ5q/wopm4iN9Dvz5pnDd9nY
F24IJrSwiLQWQRSzmldRsCFaSfPth7s2cKMLdTYEIXkGCUmwFCnGDY43OCsoQVYC
Qz3sPXORXQCk3dsOvAJbJ75Zn3GeHa0LTRVLuQdn2slu3TvqyVXih5JqxkmHD0ld
D6ZtQBYfvk6z7Xug6GZFA52j7i8kZw+XBk3YgQuLTYpP8EkZlDsUDby/3SylDawU
6jpfTbU7c1es8EPqmEAjL/iC4LM9qJrnRcuTDqQyYCG5du+Y9UoBsm+FBros4Do=
=Gpfr
-----END PGP SIGNATURE-----
Nenhum comentário:
Postar um comentário