Autorisation refusée pour un seul fichier dans un répertoire en tant qu'utilisateur root sur un système de fichiers ext3 sous RAIDiator OS

9

J'ai une boîte ReadyNAS nommée "stockage" qui, je crois, est basée sur Debian. Je peux y accéder en tant que root. J'essaie de reconfigurer le serveur Web, mais je rencontre un problème d'autorisations de fichiers que je ne comprends tout simplement pas. Je ne peux rien faire /etc/frontview/apache/apache.pemmême avec root! Il ne semble pas avoir d'autorisations spéciales par rapport aux autres fichiers du même répertoire et je peux travailler avec ceux-ci.

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

Quelle est la particularité de ce fichier qu'il est impossible de le toucher? Je ne peux pas le supprimer. Je ne peux pas changer les autorisations dessus. Je ne peux pas en changer le propriétaire.

Le répertoire semble être bien. Il reste de l'espace, il n'est pas monté en lecture seule. En fait, je peux éditer d'autres fichiers dans le même répertoire.

# 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
la source
Veuillez également afficher la sortie de ls -ld /etc/frontview/apacheet df /etc/frontview/apache. Peut-être que le dossier est sur un espace disque monté ro?
Ned64
J'ai ajouté cette information à la question. Tout me va bien. En tout cas, si tel était le problème, je ne pense pas que je pourrais modifier tous les autres fichiers de ce répertoire.
Stephen Ostermiller
@RunCMD J'ai ajouté des informations plus spécifiques au titre et aux tags. Le système de fichiers est répertorié comme ext3, donc ext3 semble prendre en charge immuable # mount::/dev/hdc1 on / type ext3 (rw,noatime)
Stephen Ostermiller
1
Solaris ne prend pas en charge les processeurs ext3 ni ARM, ce qui n'est probablement pas basé sur Solaris.
alanc
1
J'ai supprimé Solaris de la question. À la lecture, il peut être basé sur Debian Etch.
Stephen Ostermiller

Réponses:

9

Je viens de trouver le problème. L'attribut "immuable" a été défini sur ce fichier. lsne le montre pas. Vous avez besoin d'une commande différente pour le voir:

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

Une fois que j'ai supprimé le bit immuable, je peux modifier ce fichier:

# chattr -i apache.pem
# touch apache.pem
Stephen Ostermiller
la source
1
J'ai cliqué sur cette question dans les "questions réseau à chaud" pour vous dire de vérifier les attributs étendus, mais je suppose que vous l'avez déjà fait. (IDK pourquoi GNU lsn'a pas d'option pour lister les attributs. J'oublie, mais peut-être même que l'appel système pour les interroger n'est pas portable, donc il était probablement plus facile de les implémenter dans un utilitaire séparé.)
Peter Cordes
@PeterCordes Je suis d'accord. Je suis sûr d'avoir réglé ce bit après avoir recherché quelque chose comme "arrêter la mise à niveau du fichier de remplacement", mais c'était il y a des années et j'ai clairement oublié de le faire. Ce serait bien si lsle bit était affiché, ou si l'une des autres commandes que j'utilisais avait des messages d'erreur plus utiles (et spécifiques) expliquant pourquoi les autorisations ont été refusées.
Stephen Ostermiller
Tout le monde touchsait, c'est que l'appel système avec lequel il a tenté ( open("apache.pem", O_WRONLY|O_CREAT|..., 0666)) a échoué EACCESS. (Utilisez strace -efile touch apache.pempour voir les appels système liés aux fichiers qu'il effectue). Comme l' indique la page de manuel de cet appel système , il existe de nombreuses raisons possibles pour EACCESS, et beaucoup d'entre elles impliquent des répertoires parents plutôt que le fichier lui-même. Écrire du code pour déduire avec précision pourquoi un appel système a renvoyé l'erreur qu'il a faite serait extrêmement difficile, car les différents systèmes de fichiers et systèmes d'exploitation sont différents ...
Peter Cordes
Quoi qu'il en soit, la convention universelle est que lorsque quelque chose échoue, vous recherchez la chaîne d'erreur pour le code d'erreur ( errno) et l'imprimez. (Utilisation de la perrorfonction de bibliothèque standard C , ou équivalent). C'est l'un des rares cas où ce n'est pas toujours un indice suffisant pour que l'utilisateur trouve rapidement le problème, mais la plupart du temps, cela fonctionne très bien. (Surtout lorsqu'il est combiné avec straceen cas de doute quant à l'opération qui a produit l'erreur.) Ce n'est pas parfait, mais cela pourrait être bien pire (cf. MS Windows où au mieux vous obtenez un code d'erreur pour google.)
Peter Cordes
Vient de jouer avec chattr +i, et a remarqué que rm foo(sans -f) invites: rm: remove write-protected regular file ‘foo’. Parce que faccessat(AT_FDCWD, "/var/tmp/foo", W_OK) = -1 EACCES (Permission denied). POSIX nécessite rmd'inviter par défaut avant de supprimer les fichiers protégés en écriture, et c'est pourquoi il vérifie en premier lieu. Vous auriez donc obtenu un indice plus rapide si vous ne l'aviez pas utilisé rm -f. : / access(3)demande au noyau de vérifier les permissions comme s'il s'ouvrait vraiment en écriture, donc il récupère les ACL et les attributs.
Peter Cordes