Permissão negada para apenas um único arquivo em um diretório como usuário root em um sistema de arquivos ext3 no RAIDiator OS

Eu tenho uma caixa ReadyNAS chamada "storage" que acredito ser baseada no Debian. Eu posso ssh nele como root. Estou tentando reconfigurar o servidor da web, mas estou com um problema de permissão de arquivo que simplesmente não entendo. Não posso fazer nada com /etc/frontview/apache/apache.pemraiz! Parece não ter permissões especiais em comparação com outros arquivos no mesmo diretório e posso trabalhar com eles.

storage:~# whoami 
root
storage:~# cd /etc/frontview/apache/   
storage:/etc/frontview/apache# ls -lah apache.pem*         
-rw-------    1 admin    admin        4.0k Jul 10  2013 apache.pem
-rw-------    1 admin    admin        4.0k Jun  9 05:57 apache.pem.2017-02-04
-rw-------    1 admin    admin        1.5k Jun  9 05:57 apache.pem.orig
storage:/etc/frontview/apache# touch apache.pem            
touch: creating `apache.pem': Permission denied
storage:/etc/frontview/apache# touch apache.pem.2017-02-04 
storage:/etc/frontview/apache# rm -f apache.pem
rm: cannot unlink `apache.pem': Operation not permitted

O que há de tão especial neste arquivo que não pode ser tocado? Não consigo deletá-lo. Não posso alterar as permissões nele. Não posso mudar de dono.

O diretório parece estar bem. Ele tem espaço restante, não é montado como somente leitura. Na verdade, eu posso editar outros arquivos no mesmo diretório.

# ls -ld /etc/frontview/apache
drwxr-xr-x    8 admin    admin        4096 Jun  9 05:44 /etc/frontview/apache
# df /etc/frontview/apache
Filesystem           1k-blocks      Used     Available Use% Mounted on
/dev/hdc1            2015824        504944   1510880   26% /

— Stephen Ostermiller
fonte

Por favor, mostre também a saída de ls -ld /etc/frontview/apachee df /etc/frontview/apache. Talvez a pasta esteja em um espaço em disco montado ro?

— Ned64

Eu adicionei essa informação à pergunta. Tudo parece bom para mim. De qualquer forma, se esse fosse o problema, não acho que poderia editar todos os outros arquivos desse diretório.

— Stephen Ostermiller

@RunCMD Adicionei informações mais específicas ao título e às tags. O sistema de arquivos é listado como ext3, então ext3 pareceria para apoiar imutável: # mount:/dev/hdc1 on / type ext3 (rw,noatime)

— Stephen Ostermiller

O Solaris não suporta ext3 nem cpu ARM, portanto isso provavelmente não é baseado no Solaris.

— 9789 alanc #

Eu removi o Solaris da pergunta. Em leituras adicionais, pode ser baseado no Debian Etch.

— Stephen Ostermiller

Acabei de encontrar o problema. O atributo "imutável" foi definido nesse arquivo. lsnão mostra isso. Você precisa de um comando diferente para vê-lo:

# lsattr apache.pem*
----i--------- apache.pem
-------------- apache.pem.2017-02-04
-------------- apache.pem.orig

Depois de remover o bit imutável, posso editar esse arquivo:

# chattr -i apache.pem
# touch apache.pem

— Stephen Ostermiller
fonte

Eu cliquei nessa pergunta nas "perguntas da rede quente" para pedir para você verificar os atributos estendidos, mas acho que você já fez. (IDK porque o GNU lsnão tem uma opção para listar atributos. Eu esqueço, mas talvez até o sistema solicite uma consulta não seja portátil, por isso foi provavelmente mais fácil implementá-los em um utilitário separado.)

— Peter Cordes

@PeterCordes Concordo. Tenho certeza de que defini esse aspecto após pesquisar no Google algo como "interromper a atualização do arquivo sobrescrito", mas isso foi anos atrás e eu claramente me esqueci disso. Seria bom se lsmostrasse esse bit ou se algum dos outros comandos que eu usei tivesse mensagens de erro mais úteis (e específicas) sobre o motivo pelo qual as permissões foram negadas.

— Stephen Ostermiller

Todos touchsabem é que o sistema que chamou de tentativa ( open("apache.pem", O_WRONLY|O_CREAT|..., 0666)) falhou EACCESS. (Use strace -efile touch apache.pempara ver as chamadas do sistema relacionadas a arquivos que ele faz). Como diz a página de manual da chamada de sistema , existem muitos motivos possíveis para o EACCESS, e muitos deles envolvem diretórios-pai e não o próprio arquivo. Escrever código para precisão deduzir por que uma chamada de sistema retornou o erro aconteceu seria extremamente difícil, uma vez que diferentes sistemas de arquivos e sistemas operacionais são diferentes ...

— Peter Cordes

De qualquer forma, a convenção universal é que, quando algo falha, você procura a string de erro para o código de erro ( errno) e imprime isso. (Usando a perrorfunção de biblioteca padrão C , ou equivalente). Esse é um dos casos raros em que isso nem sempre é uma dica suficiente para o usuário encontrar rapidamente o problema, mas na maioria das vezes funciona muito bem. (Especialmente quando combinado com o stracecaso de haver alguma dúvida sobre exatamente qual operação produziu o erro.) Não é perfeito, mas pode ser muito pior (cf. MS Windows, onde na melhor das hipóteses você obtém um código de erro para o google.)

— Peter Cordes

Estava apenas a brincar com chattr +i, e notou que rm foo(sem -f) prompts: rm: remove write-protected regular file ‘foo’. Porque faccessat(AT_FDCWD, "/var/tmp/foo", W_OK) = -1 EACCES (Permission denied). O POSIX exige rmque seja solicitado por padrão antes de remover arquivos protegidos contra gravação e, por isso, verifica-o em primeiro lugar. Então, você teria uma grande pista mais rapidamente se não tivesse usado rm -f. : / access(3)solicita que o kernel verifique as permissões como se estivesse realmente abrindo para gravação, para pegar as ACLs e os atributos.

— Peter Cordes