Permiso denegado solo para un único archivo en un directorio como usuario root en un sistema de archivos ext3 en el sistema operativo RAIDiator

9

Tengo un cuadro ReadyNAS llamado "almacenamiento" que creo que se basa en Debian. Puedo usarlo como root. Estoy tratando de reconfigurar el servidor web, pero me encuentro con un problema de permisos de archivos que simplemente no entiendo. ¡No puedo hacer nada /etc/frontview/apache/apache.pemincluso como root! No parece tener ningún permiso especial en comparación con otros archivos en el mismo directorio y puedo trabajar con ellos.

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

¿Qué tiene de especial este archivo que no se puede tocar? No puedo borrarlo No puedo cambiar los permisos en él. No puedo cambiar el dueño de la misma.

El directorio parece estar bien. Le queda espacio, no está montado de solo lectura. De hecho, puedo editar otros archivos en el mismo directorio.

# 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% /
files permissions root ext3 Stephen Ostermiller
fuente
Por favor, muestre también la salida de ls -ld /etc/frontview/apachey df /etc/frontview/apache. Tal vez la carpeta está en un espacio en disco montado ro?
Ned64
Agregué esa información a la pregunta. Todo me parece bien. En cualquier caso, si ese fuera el problema, no pensaría que podría editar cualquier otro archivo en ese directorio.
Stephen Ostermiller
@RunCMD Agregué información más específica al título y las etiquetas. El sistema de archivos aparece como ext3, por lo que parece que ext3 admite inmutable # mount::/dev/hdc1 on / type ext3 (rw,noatime)
Stephen Ostermiller
1
Solaris no admite CPU ext3 ni ARM, por lo que probablemente no esté basado en Solaris.
alanc
1
Eliminé Solaris de la pregunta. En lecturas adicionales, puede estar basado en Debian Etch.
Stephen Ostermiller

Respuestas:

9

Acabo de encontrar el problema. El atributo "inmutable" se estableció en ese archivo. lsno lo muestra Necesita un comando diferente para verlo:

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

Una vez que elimino el bit inmutable, puedo editar ese archivo:

# chattr -i apache.pem
# touch apache.pem
Stephen Ostermiller
fuente
1
Hice clic en esta pregunta en las "preguntas de la red activa" para decirle que verifique los atributos extendidos, pero supongo que ya lo hizo. (IDK por qué GNU lsno tiene una opción para enumerar los atributos. Lo olvido, pero tal vez incluso la llamada del sistema para consultarlos no es portátil, por lo que probablemente fue más fácil implementarlos en una utilidad separada).
Peter Cordes
@PeterCordes estoy de acuerdo. Estoy seguro de que configuré ese bit después de buscar en Google algo como "detener la actualización de sobrescribir el archivo", pero eso fue hace años y claramente olvidé hacerlo. Sería bueno si lsmostrara ese bit, o si alguno de los otros comandos que utilicé tuviera mensajes de error más útiles (y específicos) sobre por qué se negaron los permisos.
Stephen Ostermiller
Todo touchlo que se sabe es que la llamada al sistema que intentó ( open("apache.pem", O_WRONLY|O_CREAT|..., 0666)) falló EACCESS. (Use strace -efile touch apache.pempara ver las llamadas al sistema relacionadas con el archivo que hace). Como dice la página del manual para esa llamada al sistema , hay muchas razones posibles para EACCESS, y muchas de ellas involucran directorios principales en lugar del archivo en sí. Escribir código para deducir con precisión por qué una llamada al sistema devolvió el error que cometió sería extremadamente difícil, ya que los diferentes sistemas de archivos y sistemas operativos son diferentes ...
Peter Cordes
De todos modos, la convención universal es que cuando algo falla, busca la cadena de error para el código de error ( errno) e imprime eso. (Usando la perrorfunción de biblioteca estándar C , o equivalente). Este es uno de los raros casos en los que eso no siempre es una pista suficiente para que el usuario encuentre rápidamente el problema, pero la mayoría de las veces funciona muy bien. (Especialmente cuando se combina straceen caso de que haya alguna duda sobre exactamente qué operación produjo el error). No es perfecto, pero podría ser mucho peor (cf. MS Windows donde, en el mejor de los casos, obtienes un código de error para google).
Peter Cordes
Fue simplemente jugando con chattr +i, y se dio cuenta de que rm foo(sin -f) indicaciones: rm: remove write-protected regular file ‘foo’. Debido faccessat(AT_FDCWD, "/var/tmp/foo", W_OK) = -1 EACCES (Permission denied). POSIX requiere rmque se le solicite de forma predeterminada antes de eliminar archivos protegidos contra escritura y, por eso, se comprueba en primer lugar. Entonces habrías obtenido una gran pista más rápido si no lo hubieras usado rm -f. : / access(3)le pide al núcleo que verifique los permisos como si realmente se estuviera abriendo para escribir, por lo que recoge las ACL y los atributos.
Peter Cordes