Ajustando as permissões de acesso

Com esta configuração, os clientes conseguem visualizar os arquivos da pasta normalmente, mas ainda não conseguem gravar nos arquivos. Ao tentar salvar alguma coisa na pasta, você recebe uma mensagem de acesso negado:

13eb6497

Isso acontece por dois motivos. O primeiro é que o default do Samba é compartilhar com permissão apenas para leitura. Como não dissemos nada sobre as permissões de acesso do compartilhamento no arquivo de configuração, ele foi compartilhado usando o default.

Para que o compartilhamento fique disponível com permissão de leitura e escrita, precisamos adicionar a opção “writable = yes” dentro da configuração do compartilhamento, que ficará:

[arquivos]
path = /mnt/arquivos
writable = yes
comment = Teste

Muito provavelmente, mesmo depois de reiniciar o Samba você continuará recebendo o mesmo erro ao tentar gravar os arquivos. Dessa vez, o Samba autoriza a gravação, mas ela ainda pode ser abortada se as permissões da pasta não permitirem que o usuário grave arquivos. Se você criou a pasta “/mnt/arquivos” como root, então o default é que apenas ele possa gravar arquivos na pasta. Para permitir que outros usuários possam gravar, é necessário abrir as permissões da pasta.

A esta altura, a lei do mínimo esforço diria para você usar um:

# chmod 777 /mnt/arquivos

Obviamente, isso permitiria que os usuários gravassem na pasta. O problema é que as permissões ficariam escancaradas, a ponto de qualquer um, que tenha acesso ao servidor (por qualquer meio) possa alterar os arquivos dentro da pasta, o que não é nada bom do ponto de vista da segurança.

No tópico sobre o Swat, vimos como criar um grupo usando o users-admin (system-config-users) e abrir as permissões da pasta apenas para os usuários que fazem parte dele. Vamos ver agora como fazer isso via linha de comando.

O primeiro passo é criar um grupo para os usuários que poderão fazer alterações na pasta, usando o comando “groupadd”. Eu prefiro criar grupos com o mesmo nome do compartilhamento, para ficar mais fácil de lembrar, mas isso fica a seu critério.

# groupadd arquivos

A partir daí, você pode adicionar usuários ao grupo usando o comando “adduser”, nesse caso especificando o usuário já criado e o grupo ao qual ele será adicionado, como em:

# adduser joao arquivos
# adduser maria arquivos

Para remover usuários do grupo, você usa o comando “deluser”, como em:

# deluser joao arquivos
# deluser maria arquivos

Depois de criar o grupo e adicionar os usuários a ele, falta apenas ajustar as permissões de acesso da pasta, de forma que o grupo tenha acesso completo, como em:

# chgrp arquivos /mnt/arquivos
# chmod 775 /mnt/arquivos

Com isso, trocamos o grupo dono da pasta e dizemos que tanto o dono quanto o grupo possuem acesso completo. A partir desse ponto, o Samba autoriza o acesso para todos os usuários cadastrados através do smbpasswd e o sistema autoriza a gravação para todos os usuários que fazem parte do grupo.

Se você precisar que a alteração seja aplicada de forma recursiva, alterando as permissões de todas as subpastas e arquivos, adicione a opção “-R” nos dois comandos, como em:

# chgrp -R arquivos /mnt/arquivos
# chmod -R 775 /mnt/arquivos

Além de servirem para controlar as permissões de acesso dos usuários às pastas do sistema, os grupos podem ser usados para ajustar as permissões de acesso do Samba, de forma bastante simples.

Se você quer que o compartilhamento fique disponível apenas para os usuários que cadastrou no grupo “arquivos”, adicione a opção “valid users = +arquivos” na seção referente ao compartilhamento. O “+” indica que se trata de um grupo e não de um usuário isolado. O Samba verifica então quais usuários fazem parte do grupo e autoriza o acesso. A partir daí, quando você quiser liberar o acesso para um novo usuário, basta adicioná-lo ao grupo:

[arquivos]
path = /mnt/arquivos
writable = yes
valid users = +arquivos

Você pode também especificar uma lista de usuários isolados, separando-os por vírgula, por espaço, ou pelos dois combinados (o que preferir), como em:

[arquivos]
path = /mnt/arquivos
writable = yes
valid users = joao, maria, jose

É possível também combinar as duas coisas, indicando um ou mais grupos e também alguns usuários avulsos, como em:

[arquivos]
path = /mnt/arquivos
writable = yes
valid users = +arquivos, jose, joaquim, +admin

Assim como na maioria das opções do Samba, a opção “valid users” é exclusiva, ou seja, ao dizer que os usuários do grupo arquivos devem ter acesso, você automaticamente exclui todos os outros. Você pode também fazer o oposto, criando uma lista de usuários que não devem ter acesso e mantendo o acesso para os demais. Nesse caso, você usaria a opção “invalid users”, como em:

[arquivos]
path = /mnt/arquivos
writable = yes
invalid users = jose, joaquim

Nesse caso, todos os usuários cadastrados no Samba podem acessar, com exceção dos usuários jose e joaquim. É possível ainda usar a opção “invalid users” para especificar exceções ao especificar grupos usando a opção “valid users”, como em:

[arquivos]
path = /mnt/arquivos
writable = yes
valid users = +arquivos
invalid users = joao

Nesse caso, todos os usuários dentro do grupo arquivos terão acesso, com exceção do joao. Esta combinação pode ser usada em casos onde o grupo é especificado também em outros compartilhamentos e você precisa bloquear o acesso do usuário a um compartilhamento específico, sem removê-lo do grupo.

É possível também criar uma lista de escrita, usando a opção “write list”. Ela cria uma camada adicional de proteção, permitindo que, dentro do grupo de usuários com acesso ao compartilhamento, apenas alguns tenham permissão para alterar os arquivos, como em:

[arquivos]
path = /mnt/arquivos
writable = no
valid users = +arquivos
write list = maria

Nesse caso, usamos a opção “writable = no”, que faz com que o compartilhamento passe a ser somente-leitura. A seguir, especificamos que os usuários do grupo “arquivos” devem ter acesso (somente-leitura) e usamos a opção “write list = maria” para criar uma exceção, dizendo que a maria pode escrever na pasta. É importante notar que, neste exemplo, a maria deve fazer parte do grupo “arquivos”, caso contrário teríamos uma situação interessante, onde ela não consegue alterar os arquivos no compartilhamento, pois não tem acesso a ele em primeiro lugar. 🙂

Caso a maria não estivesse cadastrada no grupo, você deveria incluir o login na opção “valid users”, como em:

[arquivos]
path = /mnt/arquivos
writable = no
valid users = +arquivos, maria

write list = maria

Podemos também fazer o oposto, restringindo a escrita para alguns usuários, mas mantendo o acesso para todos os demais. Nesse caso, usamos a opção “read list” para criar uma lista de exceções, como em:

[arquivos]
path = /mnt/arquivos
writable = yes
valid users = +arquivos, +admin
read list = maria, jose

Nesse exemplo, usamos a opção “writable = yes” e especificamos que os usuários dentro dos grupos “arquivos” e “admin” tem acesso ao compartilhamento. Em seguida, usamos a opção “read list” para limitar o acesso dos usuários maria e jose, de forma que eles possam apenas ler, sem alterar os arquivos dentro da pasta.

Outra opção relacionada é a “read only”, que também aceita os valores “yes” e no”. Na verdade, ela tem a mesma função da opção “writable”, apenas usa uma lógica invertida. Dizer “writable = yes” ou dizer “read only = no” tem exatamente o mesmo efeito, como seis e meia-dúzia. Em geral, você usa uma ou outra de acordo com o contexto, como uma forma de tornar o arquivo mais legível, como em:

[modelos]
path = /mnt/modelos
read only = yes

Continuando, é possível restringir o acesso também com base no endereço IP ou no nome da máquina a partir da qual o usuário está tentando acessar o compartilhamento. Isso permite adicionar uma camada extra de segurança no acesso a arquivos importantes, já que além do login e senha, é verificado a partir de qual máquina o acesso é proveniente.

Isso é feito através das opções “hosts allow” e “hosts deny” que permitem, respectivamente, criar uma lista de máquinas que podem e que não podem acessar o compartilhamento. As listas podem incluir tanto os endereços IP quanto os nomes das máquinas.

Para restringir o acesso ao compartilhamento a apenas duas máquinas específicas, você usaria:

[arquivos]
path = /mnt/arquivos
writable = yes
hosts allow = 192.168.1.23, 192.168.1.24

ou

[arquivos]
path = /mnt/arquivos
writable = yes
hosts allow = sparta, athenas

É possível também fazer o inverso, bloqueando o compartilhamento para acessos provenientes das duas máquinas. Nesse caso, mesmo que o usuário tente acessar usando um login válido, vai receber a mensagem de acesso negado, como se o login tivesse sido bloqueado ou a senha tenha sido alterada. A lista não possui um tamanho máximo, você pode incluir quantas máquinas precisar, separando os endereços ou nomes por vírgula e espaço. Você pode inclusive misturar endereços IP com nomes de máquinas, como nesse exemplo:

[arquivos]
path = /mnt/arquivos
writable = yes
hosts deny = 192.168.1.23, athenas

É possível ainda combinar a restrição com base nos nomes e endereços com a restrição com base nos logins de acesso, de forma que o acesso seja autorizado apenas quando as duas condições forem satisfeitas.

Para permitir que apenas a maria e o joao acessem o compartilhamento e ainda assim apenas se estiverem usando uma das duas máquinas permitidas, você usaria:

[arquivos]
path = /home/arquivos
writable = yes
valid users = maria, joao
hosts allow = 192.168.1.23, 192.168.1.24

Você pode autorizar ou restringir o acesso para uma faixa inteira de endereços omitindo o último octeto do endereço. Por exemplo, para que apenas clientes dentro da rede “192.168.1.x” tenham acesso, você inclui apenas a parte do endereço referente à rede, omitindo o octeto referente ao host, como em:

[arquivos]
path = /mnt/arquivos
writable = yes
hosts allow = 192.168.1.

Se precisar criar exceções, limitando o acesso a algumas máquinas dentro da faixa de endereços especificada, você pode usar a opção “EXCEPT” para especificar as exceções, como em:

[arquivos]
path = /mnt/arquivos
writable = yes
hosts allow = 192.168.1. EXCEPT 192.168.1.23, 192.168.1.24

Com isso, todos os endereços dentro da faixa teriam acesso, com exceção do .23 e do .24. O mesmo pode ser feito ao usar a opção “hosts deny”, como em:

[restrito]
path = /mnt/sda2/restrito
writable = yes
valid users = isac
hosts deny = 192.168.1. EXCEPT 192.168.1.23

Aqui a lógica é invertida e todos os hosts dentro da faixa de endereços são bloqueados, com exceção do .23, que passa a ser o único aceito pelo servidor.

Outro parâmetro que pode ser usado ao criar exceções é o “ALL”, que inclui todos os endereços possíveis. Se a idéia é que apenas um determinado endereço possa acessar o compartilhamento, uma opção é usar “hosts deny = ALL EXCEPT 192.168.1.34”.

O default do Samba é permitir o acesso a partir de qualquer máquina, de forma que se você não usar nem a opção “hosts allow”, nem a “hosts deny”, qualquer máquina poderá acessar o compartilhamento.

Ao usar apenas a opção “hosts allow”, apenas as máquinas listadas terão acesso ao compartilhamento, as demais serão recusadas. Ao usar apenas a opção “hosts deny”, apenas as máquinas listadas não terão acesso ao compartilhamento (as demais continuam acessando).

Ao combinar o uso das opções “hosts allow” e “hosts deny”, a opção “hosts allow” tem precedência (não importa a ordem em que elas sejam colocadas), de forma que as máquinas listadas terão acesso, mesmo que ele seja negado pela opção “hosts deny”. Por exemplo, ao usar:

[isos]
path = /mnt/isos
hosts allow = 192.168.1.
hosts deny = 192.168.1.43
comment = Algo está errado

… o host “192.168.1.43” continuará tendo acesso ao compartilhamento, pois faz parte da faixa de endereços cujo acesso é autorizado pela opção “hosts allow”. Neste caso, o Samba não considera a opção “hosts deny = 192.168.1.43” como uma exceção, mas sim como um erro de configuração. Para bloquear a máquina, você deveria usar:

[isos]
path = /mnt/isos
hosts allow = 192.168.1. EXCEPT 192.168.1.43
comment = Agora sim

Em situações onde você precisa restringir temporariamente o acesso a um determinado compartilhamento (para alguma tarefa de manutenção, por exemplo) você pode usar a opção “available = no”, como em:

[arquivos]
path = /home/arquivos
writable = yes
valid users = maria, joao
available = no

Ela faz com que o compartilhamento “desapareça”, da mesma forma que se você apagasse ou comentasse a configuração. A principal vantagem é que ao apagar você precisaria escrever tudo de novo para reativar o compartilhamento, enquanto ao usar o “available = no” você precisa apenas remover a opção ou mudar para “available = yes”.

Outra opção interessante que pode ser incluída é a “browseable = no”, que transforma o compartilhamento em um compartilhamento oculto:

[arquivos]
path = /home/arquivos
writable = yes
browseable = no

Com isso, ele não aparece mais no ambiente de redes, mas pode ser acessado normalmente se você especificar o nome manualmente ao mapear o compartilhamento:

3807903d

Essa não é propriamente uma opção de segurança, mas pode ser usada para afastar os curiosos dos compartilhamentos com acesso restrito.

Concluindo, muitas opções que ficam disponíveis no Swat podem ser omitidas ao configurar manualmente, simplesmente porque são o default no Samba. O próprio Swat evita incluir opções redundantes ao gerar o arquivo, incluindo apenas as configurações que são diferentes dos valores default.

Não é necessário incluir opções como “writable =no”, “available = yes” ou “browseable = yes” no arquivo, pois estes já são os valores usados por padrão no Samba. Apesar disso, usá-los também não atrapalha em nada, de forma que nada impede que você os inclua no arquivo para se lembrar mais facilmente das opções.

Outra dica é que você pode verificar a qualquer momento quais usuários e quais máquinas estão acessando compartilhamentos no servidor usando o comando “smbstatus, como em:”

# smbstatus

Samba version 3.0.24
PID Username Group Machine
——————————————————————-
17107 gdh gdh hp (192.168.1.2)
11588 gdh gdh semprao (192.168.1.10)

Service pid machine Connected at
——————————————————-
IPC$ 17107 hp Sun Oct 28 15:54:04 2007
arquivos 11588 semprao Sun Oct 28 15:23:59 2007

No locked files

Neste exemplo, podemos ver que o usuário “gdh” está logado no servidor a partir de duas máquinas diferentes, um indício de que duas pessoas estão utilizando a mesma conta.

Sobre o Autor

Redes Sociais:

Deixe seu comentário

X