Como eu, como usuário normal, sou capaz de alterar a propriedade de um arquivo?

Question

Eu tenho uma partição que é montada em NFS a partir de uma rede Netapp SAN. Eu posso criar arquivos nessa partição, e eu posso chown esses arquivos para outro usuário, qualquer usuário, mesmo root. Como posso fazer isso? Eu pensei que o kernel impediria tal coisa. Eu fiz isso de novo e de novo hoje, usando vários id de usuário no arquivo.

Não consigo fazer isso em / tmp ou no meu diretório pessoal, que é montado localmente.

Eu nunca vi esse comportamento antes. Além disso, noto que o setcap / getcap não é encontrado nesta máquina.

Eu verifiquei os recursos do meu shell e eles são todos de 0:

$ echo $$
15007
$ cat /proc/15007/task/15007/status 
Name:   bash
State:  S (sleeping)
SleepAVG:       98%
Tgid:   15007
Pid:    15007
PPid:   14988
TracerPid:      0
Uid:    71579   71579   71579   71579
Gid:    10000   10000   10000   10000
FDSize: 256
Groups: 9000 10000 10001 10013 10018 10420 24611 36021 
...
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000

Estou em uma máquina virtual Red Hat 5.3:

$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.3 (Tikanga)

Executando um kernel antigo:

$ uname -r
2.6.18-274.7.1.el5

A montagem do NFS usa padrões:

$ cat /etc/fstab
...
mynetapp00:/home /mnt/home nfs defaults 0 0

Para a autenticação do usuário, estamos usando o Windows Active Directory com o ldap no lado do Linux:

$ grep passwd /etc/nsswitch.conf 
passwd:     files ldap

Eu sou capaz de fazer algo como sudo:

User mikes may run the following commands on this host:
    (ALL) ALL

porque eu sou um dos ADMINS (conteúdo de / etc / sudoers):

User_Alias      ADMINS = fred, tom, mikes
ADMINS          ALL=(ALL) ALL

... Mas eu não sei como isso é germaine, porque o sudo não está envolvido. De qualquer forma, eu fui capaz de criar um arquivo e dar a minha propriedade como um usuário "joão" que não foi encontrado em / etc / sudoers:

# grep john /etc/sudoers
# su - john
$ touch /mnt/home/blah
$ chown mikes /mnt/home/blah   
$ ls -l /mnt/home/blah
-rwxrwxrwx 1 mikes DomainUsers 0 Oct 23 19:45 /mnt/home/blah

... e o chown não tem um alias (mas nós sabíamos disso, porque se o chown fosse um alias ou algum outro programa, eu também seria capaz de alterar a propriedade em / tmp):

$ alias
alias l.='ls -d .* --color=tty'
alias ll='ls -l --color=tty'
alias ls='ls --color=tty'
alias vi='vim'
alias which='alias | /usr/bin/which --tty-only --read-alias --show-dot --show-tilde'
$ which chown
/bin/chown

P.S. Eu não estou brincando:

$ id
uid=71579(mikes) gid=10000(DomainUsers)
$ touch /mnt/home/blah
$ chown john /mnt/home/blah
$ ls -l /mnt/home/blah
-rwxrwxrwx 1 john DomainUsers 0 Oct 23 19:04 /mnt/home/blah
$ id john
uid=37554(john) gid=10000(DomainUsers)
$ chmod 755 /mnt/home/blah
chmod: changing permissions of '/mnt/home/blah': Operation not permitted
$ rm /mnt/home/blah
$ ls -l /mnt/home/blah
ls: /mnt/home/blah: No such file or directory
$ touch /tmp/blah
$ chown john /tmp/blah
chown: changing ownership of '/tmp/blah': Operation not permitted

    

Answer 1

Sim, chown é o alcance do kernel, mas lembre-se de que a NetApp está além do alcance do braço do kernel. Para sistemas de arquivos locais, o kernel traduz solicitações de E / S do usuário em operações de E / S de hardware local (no dispositivo de armazenamento). Para sistemas de arquivos remotos (por exemplo, NFS), o kernel traduz solicitações de E / S do usuário em comunicações de rede, perguntando / dizendo ao servidor para fazer o que o usuário quer.

Não há garantia de que o servidor fará o que foi solicitado. Por exemplo, os servidores da NetApp podem ser configurados para suportar Permissões no estilo Unix e permissões no estilo do Windows simultaneamente. Clientes Unix / Linux verão as permissões no estilo Unix (usuário, grupo, modo e talvez ACL). Clientes Windows verão as permissões no estilo do Windows (usuário, mas não grupo, atributos, ACL e talvez atributos estendidos). A NetApp armazena internamente uma combinação das propriedades do arquivo, e reforça o acesso com base em algum algoritmo proprietário obscuro, então uma operação Unix pode ser recusada por causa de uma restrição de permissão no estilo do Windows que o cliente Unix não consegue ver.

TL; DR
O servidor NetApp impõe permissões. Portanto, o driver NFS para NetApp pode ser gravado não fazer verificações de permissão, mas para enviar todas solicitações de usuários ao servidor. E assim, a decisão de permitir que o chown seja executado provavelmente está sendo feito 100% na NetApp.

Eu não sei porque isso aconteceria. Pode ser um bug. Isso me surpreenderia um pouco, já que a NetApp existe há 25 anos; Eu esperaria que um bug desse tamanho fosse reportado e corrigido agora. Pode ser uma configuração no NetApp. Isso não faz muito sentido mas talvez o administrador do servidor não entende bem o que ele está fazendo (ou talvez haja algum motivo político obscuro por que seria configurado dessa maneira).