Sudo mkdir falha devido a permissão negada erro

Question

Eu escrevi um script que copia alguns arquivos de um lugar para outro e, como não tenho permissões para a pasta de origem, tentei executá-lo com o sudo. O problema é que agora a criação das pastas de destino falha. Aqui está um caso de teste simples:

No meu diretório home, os seguintes trabalhos:

mkdir testDir

Mas isso falha devido à permissão de erro negado

sudo mkdir testDir2

Meu diretório pessoal tem 755 permissões e é de minha propriedade.

Corri sudo groups e descobri que, como esperado, o root group está lá, mas, estranhamente, o users não está. Também executando groups como eu mesmo revela que não estou no grupo sudo.

Alguma idéia do que está acontecendo? Por que não consigo escrever na minha pasta pessoal quando estou usando o sudo?

    

Answer 1

Isso se deve a "squash raiz" no servidor NFS. Na página exports(5) man (ênfase minha):

nfsd bases its access control to files on the server machine on the uid and gid provided in each NFS RPC request. The normal behavior a user would expect is that she can access her files on the server just as she would on a normal file system. This requires that the same uids and gids are used on the client and the server machine. This is not always true, nor is it always desirable.

Very often, it is not desirable that the root user on a client machine is also treated as root when accessing files on the NFS server. To this end, uid 0 is normally mapped to a different id: the so-called anonymous or nobody uid. This mode of operation (called 'root squashing') is the default, and can be turned off with no_root_squash.

Para parafrasear, geralmente é um risco de segurança permitir que o root (por exemplo, quando executando sudo ) no cliente NFS modifique arquivos e atributos de arquivos como se fossem root no servidor NFS. Isso efetivamente tornaria root no cliente equivalente a root no servidor e permitiria que um cliente não autorizado assumisse o servidor.

Do guia de segurança do RHEL 6 :

If no_root_squash is used, remote root users are able to change any file on the shared file system and leave applications infected by Trojans for other users to inadvertently execute.