Permissões x umask

Como disse no post anterior, umask é a permissão padrão para criação de arquivos e diretórios; isto é… quando criamos um arquivo ou um diretório no sistema, estes já vem com uma permissão padrão.

Todo usuário tem um valor de umask, que define a permissão padrão para criação de arquivos e diretórios. O comando para visualizar o valor da umask, é o umask; é um comando interno do bash 🙂 .

A umask é guardada em nos arquivos profiles; no /etc/profile e arquivo .bash_profile ou .profile que fica no home de cada usuário do sistema. Cada usuário pode ter o seu padrão, para isso, basta alterar o valor no arquivo .bash_profile; caso o arquivo não exista, podemos criar!

Por exemplo, vamos no terminal onde a trinity está logada e vejamos qual o valor da umask dela:

$ umask
0022

Bem, agora a questão é: sei o valor da umask… mas que permissão é essa? Para descobrir, vamos ter que fazer uma continha de padeiro.

Sei que a permissão total no sistema é 777 e o valor da umask é 022. Simplesmente eu subtraio o valor da umask do valor da permissão total:

777 – 022 = 755

Descobrimos então, que a permissão padrão para uma umask de valor 022 é 755!

Agora um detalhe! Quando falamos em permissão total, estamos falando de rwx, que em um diretório, significa:

r – Posso listar o conteúdo
w – Posso criar arquivos
x – Posso entrar no diretório

Já para arquivos, estamos falando que:

r – Posso ler o conteúdo
w – Posso alterar o conteúdo
x – Posso executar esse arquivo

Só que o detalhe é: o sistema por padrão não adota que todo arquivo criado será um executável… então a opção de x, isto é, de execução não vem setada por padrão, senão terei vários arquivos executáveis que na verdade são apenas arquivos de texto.

Assim, no caso da permissão padrão para criação de arquivos, sempre vai ser retirado o x… e temos que fazer a continha de padeiro novamente, para descobrir qual a permissão padrão para criação de arquivos, ja que acima, a permissão padrão é para diretórios!

Vejam a tabela:

Permissao para arquivos

Então, resumindo, subtraímos a permissão x que tem o valor 1, porque o Linux presume que nem todo arquivo criado será executável!

Continuando com as permissões especiais… no post anterior, vimos que tanto o neo como a trinity, já estão criando arquivos dentro do diretório /mnt/private, com o grupo private:

$ cd /mnt/private/

$ ls -l
total 0
-rw-r–r– 1 neo     private 0 2009-03-29 02:43 arquiteto.txt
-rw-r–r– 1 trinity private 0 2009-03-29 02:41 sentinelas.txt

Mas… uma coisa ainda não está certa. Vejam as permissões dos arquivos que o neo e a trinity criaram. Está como 644 (leitura e escrita para os donos, e somente leitura para o grupo e outros).

Se estamos falando de um diretório onde as pessoas que fazem parte do grupo devem conseguir ler e escrever… temos que alterar as permissões. Só que, se alterarmos as permissões na mão, da próxima vez que criar arquivos, ainda assim estarão com as permissões erradas.

Então, nessa hora entra em ação a umask… Como vimos, a trinity tem a umask 022, que é a padrão do sistema.

No caso, precisamos que para os arquivos que forem criados daqui pra frente, os usuários que façam parte do grupo private, tenham permissão de escrita também… e não somente o dono!

Para calcular a nova umask da trinity e do neo, vamos fazer conta de padeiro de novo!

Descobrindo nova umask
Bem, descobrimos que a umask que deve ser usada, é a 002. E, como comentado acima, o sistema não presume que todo arquivo criado é um executável, fazemos a continha de padeiro de novo, para saber qual a permissão padrão para os arquivos:

Novo valor de permissao para arquivos

Agora que ja sabemos o valor das permissões para criação de novos arquivos, vamos corrigir a umask dos usuários trinity e neo no arquivo .bash_profile que está no home dos usuários.

Só lembrando, dependendo da distribuição, o arquivo a ser editado é .profile dentro do diretório home do usuário.

# vim /home/trinity/.bash_profile

Localize a linha referente ao umask:

#umask 022

A linha esta comentada… descomente a linha e vamos alterar o valor da umask. Ficará assim:

umask 002

E, para que a nova umask comece a valer, basta que os usuários desloguem e loguem novamente. Ou então… para facilitar, logados como usuários trinity e neo, basta atualizar o arquivo .bash_profile ou .profile:

$ source ~/.bash_profile

E pra conferir, como usuários trinity e neo, executa o comando abaixo… que já deve sair a umask correta!

$ umask
0002

Agora, como root, vamos analisar os novos arquivos que os usuários neo e trinity criaram dentro do diretório /mnt/private:

# cd /mnt/private/

# ls -l
-rw-rw-r– 1 neo     private 0 Mai 16 10:10 zion.txt
-rw-rw-r– 1 trinity private 0 Mai 16 10:10 report.txt

Bem, a trinity criou um arquivo chamado reports.txt e o neo, um arquivo chamado zion.txt… e agora, esses arquivos já vieram com a permissão correta! No bloquinho de permissões do grupo, quem faz parte do grupo, pode editar os arquivos que eles criaram!

E ficamos aqui por enquanto! No próximo post, irei falar sobre as outras permissões especiais… faltam duas! Até la! 🙂 .

Anúncios

Permissões especiais no GNU/Linux

Continuando o post anterior sobre administração de usuários, aqui vamos falar sobre permissão especial.

Uma permissão especial, nada mais é do que um complemento das 3 permissões básicas (rwx); esse tipo de permissão afeta arquivos, arquivos executáveis ou diretórios.

As permissões especiais que temos são: stick bit, sgid bit e suid bit.

Assim como as permissões básicas possuem valores (r=4,w=2,x=1), as permissões especiais também possuem valores:

Stick bit – valor 1
Sgid bit – valor 2
Suid bit – valor 4

Vou falar sobre cada uma dessas permissões, dentro do problema que precisamos resolver. No post anterior, vimos que os usuários criaram os arquivos que herdaram as permissões do usuários tanto para dono quanto para grupo.

Então, precisamos de uma permissão especial para o grupo; no caso a SGID. Essa permissão é utilizada em diretórios; sua mágica é fazer com que tudo que for criado dentro do diretório onde definimos SGID seja do grupo do diretório e não do dono que está criando o arquivo!

Isso quer dizer que, quando definirmos o sgid bit no /mnt/private, trinity e neo vão criar os arquivos com o grupo private, pois o diretório private tem esse grupo.

Vamos adicionar então a permissão sgid no diretório:

# cd /mnt/

# chmod g+s private/

# ls -ld private/
drwxrws— 2 root private 1024 2009-03-29 02:12 private/

Acima, apenas acrescentei a permissão ‘s‘ no grupo; e o sistema trocou o x por s na permissão de grupo. Usei o comando chmod com a forma literal; mas se fosse usar a forma octal, o comando seria esse:

# chmod 2770 private/

# ls -ld private/
drwxrws— 2 root private 1024 2009-03-29 02:12 private/

Esse comando faz exatamente o que o comando ‘chmod g+s‘ faz; a diferença entre eles é que, quando uso a forma literal, preciso apenas acrescentar mais uma permissões às que já existem. Agora, quando ajusto as permissões de forma octal, tenho que falar todas as permissões (a permissão especial e as permissões que já existem).

Bem, vamos ver se funcionou! Vamos entrar no terminal onde a trinity está logada e fazer um teste!

$ cd /mnt/private

$ touch sentinelas.txt

$ ls -l
total 0
-rw-r–r– 1 neo     neo     0 2009-03-29 01:51 matrix.txt
-rw-r–r– 1 trinity trinity 0 2009-03-29 02:13 nmap.txt
-rw-r–r– 1 trinity private 0 2009-03-29 02:41 sentinelas.txt

Percebam a diferença! O primeiro arquivo que a trinity criou, o grupo está como sendo o pessoal dela! Depois da modificação que fizemos, agora o grupo do arquivo está como private!

Fazendo um teste com o usuário neo:

$ cd /mnt/private/

$ ls -l
total 0
-rw-r–r– 1 neo     private 0 2009-03-29 02:43 arquiteto.txt
-rw-r–r– 1 neo     neo     0 2009-03-29 01:51 matrix.txt
-rw-r–r– 1 trinity trinity 0 2009-03-29 02:13 nmap.txt
-rw-r–r– 1 trinity private 0 2009-03-29 02:41 sentinelas.txt

$ touch arquiteto.txt

De acordo com a saída do comando ls que o neo executou acima, agora está tudo correto: os arquivos sentinelas.txt e arquiteto.txt foram criados respeitando os donos e mantendo o grupo como sendo private.

Mas… (sempre tem um mas!) quando começamos a falar sobre adm de usuários, dissemos que o private ia ser um diretório público (para trinity e o neo).

E, quando falamos em diretório público, estamos dizendo que as permissões desse diretório será diferente das permissões que vem por padrão quando criamos um diretório (lembra que tivemos que mudar a permissão do private pra trinity e o neo poderem criar os arquivos?).

A permissão padrão do sistema, é chamada de umask. Quando criamos um diretório ou um arquivo, eles já saem criados com uma permissão padrão. O responsável por essa permissão, é nada mais nada menos do que a umask.

Se analisarmos as permissões dos arquivos que os usuários criaram, eles estão vindo com a permissão padrão… o dono pode ler e escrever, mas o grupo só pode ler!

Isso quer dizer que, mesmo que o usuário faça parte do grupo private, não pode escrever no arquivo, uma vez que os arquivos criados estão com permissão 644! Bem… precisamos corrigir isso!

No próximo post, vou comentar sobre a umask para resolver esse problema da permissão de escrita para grupo! Até la! 😀

Entendendo as permissões no Linux

No post anterior, falamos sobre a criação de usuários. Agora, vamos falar sobre as permissões de acesso nos diretórios que foram criados.

A primeira coisa que temos que entender quando falamos em controlar os acessos, são as permissões.

Permissão, antes de tudo, é o que o usuário pode ou não fazer quando está logado no sistema.

Quando executamos o comando:

# ls -ld /mnt/private/
drwxr-xr-x 2 root private 1024 2009-01-02 00:27 /mnt/private/

Na saída do comando acima, temos várias informações sobre o diretório /mnt/private… mas o que vamos analisar nessa saída, são as permissões do diretório, representadas pela sopa de letrinhas rwxr-xr-x.

Ahn, para conhecer os campos da saída do comando ls de forma detalhada, pode dar uma lida no post em que falei sobre o comando ls.

Bem, vamos lá… essa sopa de letrinhas que comentei acima, é a responsável por definir o que é chamado de permissão no Linux. Isso quer dizer que, esse conjunto de letras, irá permitir que usuários possam gravar, ler, ou entrar em um diretório!

No Linux, qualquer arquivo ou diretório precisa ter um dono, um grupo e permissões; ou seja, vamos ter 3 permissões e 3 pessoas que vão usar essas permissões.

Permissoes e usuariosNa tabela acima temos as permissões que podemos designar para os usuários (rwx) e as pessoas que vão usar as permissões (ugo).

Isso quer dizer que sempre temos que falar se o usuário (u), poderá ler, escrever ou executar um arquivo ou diretório. Ou ainda, se o grupo (g) desse diretório vai poder ler, escrever, ou executar o arquivo ou diretório. E por último, se os outros (o), vão poder ler, escrever ou executar esse arquivo ou diretório.

Lembrando aqui que outros (other), são os usuários cadastrados no sistema que não fazem parte do grupo e nem são os donos arquivo ou diretório! É o resto 😛 .

Para mudar as permissões, usamos o comando chmod (change mode). Vamos aprender a usar esse comando. Eu comentei que damos permissão para 3 pessoas: user, group, other e que temos 3 tipos de permissões: read, write, executable.

Sabendo disso, precisamos apenas configurar as permissões que queremos para as pessoas. Ah,e detalhe… cada bloquinho de rwx, representa permissão para alguém! Exemplo:

# cd /tmp/

# touch arquivo.txt

# ls -l arquivo.txt
-rw-r–r– 1 root root 0 2009-01-28 05:54 arquivo.txt

Acima, apenas criamos um arquivo no diretório /tmp.Vamos analisar as permissões: rw-r–r– .
Como falei, cada bloquinho de rwx indica a permissão para alguém… Então, se separarmos as permissões do arquivo que acabamos de criar temos:

Permissoes

Nas permissões acima, o dono (owner) terá permissão de leitura (r) e gravação (w). O grupo (g) e os outros (o) terão permissão somente de leitura (r).
Agora, vamos mudar as permissões do arquivo.txt:

# chmod u=rwx,g=rw,o=r arquivo.txt

# ls -l arquivo.txt
-rwxrw-r– 1 root root 0 2009-01-28 05:54 arquivo.txt

Acima, apenas dissemos que o dono (u) tem permissão total, leitura(r), gravação(w) e execução (x); o grupo tem permissão de leitura (r) e gravação (g) e o resto do povo, isto é, os outros (o) tem apenas permissão de leitura (r).

E onde tem os tracinhos ‘‘, quer dizer que não tem permissão nenhuma!

Essa forma de dar permissões (usando letras) é chamada de literal; e usa operadores aritméticos… No exemplo, usei o ‘=’; mas além dele temos:

= Aplique exatamente assim

+ Adicionar mais essa

Tirar essa

Agora, pensando no diretório private, que falei logo no início do post. O pessoal que faz parte do grupo private, deve ter permissão para entrar, ler e escrever nesse diretório! Mas o usuário smith e qualquer outra pessoa que não faz parte do grupo, nem pode ver o que tem lá dentro!

Por padrão, a permissão para qualquer diretório criado é rwxr-xr-x. Então, os usuários que fazem parte do grupo private, só podem entrar e ler o conteúdo do diretório. Vamos fazer um teste tentando criar um arquivo dentro do diretório private com algum usuário (trinity ou neo):

$ whoami
trinity

trinity@nixi:~$ cd /mnt/private/

$ touch trinity.txt
touch: cannot touch `trinity.txt’: Permissão negada

Bem, a trinity, apesar de fazer parte do grupo private, não conseguiu criar um arquivo dentro do diretório! Isso acontece por conta das permissões! Vejam:

# ls -ld /mnt/private/
drwxr-xr-x 2 root private 1024 2009-01-02 00:27 /mnt/private/

No bloquinho de permissões do grupo, diz que o grupo pode ler e executar. No caso, executar seria entrar no diretório… e para escrever… nada!

Por isso que a trinity não conseguiu criar o arquivo dela! Vamos mudar isso… afinal de contas ela faz parte da diretoria, né?

Então, como root, vamos aplicar permissão de escrita para o grupo no diretório private:

# chmod u=rwx,g=rwx,o= /mnt/private

No comando acima, usando a forma literal, estamos aplicando permissão total para o dono (u), o grupo (g), e, como é o diretório que só o pessoal da diretoria vai acessar, não colocamos nada de permissão para outros (o=).

Vejam como ficou:

# ls -ld /mnt/private/
drwxrwx— 2 root private 1024 2009-01-02 00:27 /mnt/private/

Bom, aproveitando, vejam agora também a outra forma que também é utilizada para dar permissões; é o modo octal (usando números)!

Vejam a tabela:

1 – execução (x)

2 – gravação (w)

4 – leitura (r)

É a mesma lógica… só que agora, usando números!!! Sendo assim, as permissões que definimos acima, usando números, ficaria assim:

# chmod 770 /mnt/private/

# ls -ld /mnt/private/
drwxrwx— 2 root private 1024 2009-01-02 00:27 /mnt/private/

E o valor das permissões para cada pessoa, vem da soma: 4+2+1 = 7.

É importante falar que os dois modos de definir permissão (literal e octal), são bons! Mas a melhor parte da notícia, é que é você quem escolhe qual dos dois melhor se adapta.

Bem, para não se estender mais aqui, no próximo post, vou continuar falando sobre permissões! Até lá! 🙂