J'avais un bogue lorsqu'un fichier de configuration pour une application n'était pas inclus correctement. Pour essayer d'isoler la ligne problématique du fichier, j'ai copié l'ancien contenu dans un nouveau fichier, quelques lignes à la fois.
À la fin, j’avais fait une copie conforme du fichier, mais l’ancien ne fonctionnait toujours pas alors que le nouveau fonctionnait parfaitement.
Plus précisément, si j'utilise la mv
commande pour déplacer le fichier de l'endroit où je l'ai stocké à l'endroit où il se trouve, cela provoque des erreurs. Si j’ai l'habitude cp
de copier le fichier là où il veut être, il n'y a pas d'erreur.
Évidemment, des éléments tels que diff
, file
ou ls -l
ne révèlent aucune différence entre les deux fichiers, car l’un est une copie de l’autre, dans la mesure où il en cp
fait une copie exacte .
Je ne peux pas partager trop d'informations sur le fichier, car il s'agit d'un travail. L'essentiel est que les commandes cp fileA fileB
et mv fileA fileB
produisent un fileB « différent ». Ma meilleure hypothèse est qu'un attribut de très bas niveau de fileB est laissé derrière cp
( cp -p
produit même le même comportement).
Que fait mv différemment de cp en ce qui concerne le contenu exact du fichier résultant?
EDIT: avec ls -l
:
-rw-r--r--. 1 root root 3389 Aug 8 22:53 fileA
-rw-r--r--. 1 root root 3389 Aug 8 23:03 fileB
EDIT: L’application est mysql et le fichier est un fichier .cnf et l’élément de ce fichier de configuration particulièrement intéressant est le nom du journal binaire utilisé dans la réplication de la base de données maître-esclave. L'erreur "est que vous n'utilisez pas de journalisation binaire" car il n'y a pas de journal binaire car cet élément n'a jamais été "lu" par mysql.
Ma pensée initiale était qu'il y avait une erreur de syntaxe dans le fichier de configuration qui empêchait toute la lecture, ce qui m'a amené à le recréer manuellement en copiant des blocs de texte.
EDIT: Aller quelque part ... Enfin, quelque chose de différent à propos des fichiers
ls -lZ
-rw-r--r--. root root unconfined_u:object_r:user_home_t:s0 server.cnf.bad
-rw-r--r--. root root unconfined_u:object_r:mysqld_etc_t:s0 server.cnf.good
cp -p
tant qu'utilisateur régulier? Voir Pourquoi un utilisateur normal ne peut-il pas créerchown
un fichier? En général, à moins d'être root, vouscp -p
ne conserverez pas la propriété.mv
volonté.cp -a
au lieu decp -p
?ls -lZ
Réponses:
TL; DR: dans un système où SELinux est utilisé, les fichiers utilisés par le système (par exemple, les démons) doivent être copiés ou déplacés avec
cp -aZ
et à lamv -Z
place decp -a
etmv
. Si cela n'a pas été fait, il suffit d'utiliserrestorecon -v -r
ourestorecon -v -F -r
sur la destination pour demander au système de restaurer les contextes SELinux par défaut. C'est toujours une bonne idée d'utiliserrestorecon
à la fin d'un script qui a fonctionné sur des fichiers de configuration clés.RHEL et donc la plupart de ses dérivés utilisent SELinux par défaut .
Donc, pour résoudre votre problème, si votre système est basé sur RHEL et utilise le
mariadb-server
package, procédez à l'étape finale lorsque le fichier se trouve au bon endroit :(Notez que sans
-F
cela,unconfined_u
la configuration ne changerait passystem_u
. Cela n'aurait pas d'importance pour les systèmes courants. Ma connaissance de la différence et de la raison pour laquelle cela n'a aucune importance ne va pas aussi loin).Ce serait simplement plus de travail de mettre le bon contexte sur le fichier ailleurs .
chcon
peut le faire (soit en l'indiquant avec-u
-t
etc., plus simplement en copiant le contexte depuis un autre fichier avec--reference
):Si vous suspectez des problèmes avec SELinux, vérifiez les
/var/log/audit/audit.log
entrées avec le motdenied
associé à votre processus ou fichier. Vous pouvez toujours demander temporairement à SELinux d'autoriser les opérations, puis de les restaurer, avec respectivementsetenforce Permissive
etsetenforce Enforcing
pour comparer le comportement. Ne le laissez pasPermissive
spécialement pour la production.Diverses explications suivantes ...
Exemple et ce qu'il faut faire pour travailler sur des fichiers de configuration
Exemple de comportement avec diverses
cp
options etmv
sur un système activé pour SELinux:Donc, utiliser
cp -aZ
oumv -Z
fonctionne bien lorsque les contextes de sécurité importent tout en préservant les autres attributs. Un script système de fichiers doit se déplacer toujours utiliser l'-Z
option pour toutcp
oumv
commande, ou bien il suffit d' utiliserrestorecon
dans son étape finale pour éviter des problèmes inattendus.Pourquoi ces différences?
La
mv
commande conserve un comportement cohérent. Si cela se produisait dans le même système de fichiers, bien entendu tout ce qui serait attaché à un fichier, y compris son contexte de sécurité, ne serait pas modifié puisqu'il ne s'agit que d'un "renommer". Ainsi, sur deux systèmes de fichiers, où il s’agit d’une copie puis d’une suppression, il copie également tout ce qui est attaché au fichier et qui est connu, ainsi que son contexte de sécurité, pour des raisons de cohérence.La
cp
commande par défaut vient de créer un nouveau fichier, si ce fichier hérite du contexte de SELinux du parent comme d' habitude, à moins bien sûr dit autrement--preserve=context
inclus dans-a
.--preserve=context
peut être soustrait-a
à l’option de-Z
sorte que le meilleur choix lors de la copie d’arborescences entières est de l’utiliser à la-aZ
place de-a
si SELinux est important.Par défaut, lors de la création d’un fichier, ce qui est le cas habituel, ce nouveau fichier hérite du contexte du répertoire SELinux, c’est pourquoi tout fonctionne correctement le nom du noyau ne l’intéressera pas, des programmes comme le démon
restorecond
seront nécessaires pour le gérer).Qu'est-ce que SELinux?
SELinux est un mécanisme de contrôle d'accès obligatoire ( MAC ), utilisé en plus de tous les autres mécanismes (autorisations Unix aka DAC , Listes de contrôle d'accès aka ACL, etc.). Lorsqu'un processus s'exécute dans un contexte de sécurité de processus, une "matrice de règles" permet de vérifier si ce contexte de processus peut effectuer l'opération demandée (ouvrir, lire, écrire, mmap, ...) sur le contexte de fichier sur lequel il tente de travailler.
Exemple pour le cas d'OP: Si le
mysqld
contexte de processus de 's n'est autorisé qu'à accéder à quelques types de contexte de fichier, l'inclusionmysqld_etc_t
mais pas auuser_home_t
démarragemysqld
échouera car il ne pourrait pas lire son fichier de configuration avec unuser_home_t
type incorrect .Sur les systèmes habituels, cela n'a pas d'importance pour l'utilisateur interactif / connecté, car son contexte de processus habituel n'est pas confiné, ce qui signifie qu'aucune règle SELinux ne s'appliquera. Chaque démon a commencé par
systemd
ou d' autres mécanismes similaires seront recevoir un contexte de processus, ce qui peut être vérifié avecps
des »-Z
option. Exemple sur un système Debian exécutant SELinux:la source
Oui, il y a une différence principale:
Essayez ce qui suit:
Vous verrez que b est un nouveau fichier avec un nouveau numéro d'inode, où c est exactement le même fichier avec le numéro d'inode de l'ancien a.
Pourtant, cela n'explique pas votre comportement étrange.
la source
cp
ne devrait pas fonctionner correctement, ou copier le travail cassé également.cp
à créer un inode entièrement nouveau, en utilisant uniquement le nom / chemin de destination. N'oubliez pas que le code pour ces fonctionnalités peut être implémenté de nombreuses façons. Je suis sûr par exemple que cp appelle une méthode du noyau en transmettant des paramètres. ces paramètres peuvent ou non provenir de ou être lus à partir de l'inode, et il est possible que du code anti-corruption ait été ajouté d'un côté ou de l'autre, ou seulement pour un argument particulier, etc. Des hypothèses sérieuses sur le problème, si ce n'est que vous avez une corruption d'inode, et cp l'ont corrigé en créant un nouvel inode.C’est peut- être ce qui se passe (vous partagez très peu d’informations sur l’application ou ces erreurs, alors je ne peux que deviner).
Sous Linux, le verrouillage de fichier obligatoire est rare . Des appels comme
flock(2)
gérer les verrous consultatifs . Cela signifie que le noyau garde la trace des verrous mais ne les applique pas, il appartient aux applications de les respecter.Si quelque chose se verrouille
fileA
et que votre application respecte le verrou, elle peut refuser le service. Supposons que c'est ce qui se passe.Le verrou affecte inode plutôt que chemin ou nom. Déplacement (changement de nom) , le verrouillage
fileA
à l'fileB
intérieur d' un seul système de fichiers ne fait rien à l'inode, le fichier est toujours verrouillé, l'application refuse toujours de travailler avec elle. La copie du fichier crée un fichier séparéfileB
avec son propre inode qui n'est pas verrouillé, l'application fonctionne.(Remarque: déplacer un fichier vers un autre système de fichiers est en fait une copie + suppression, il devrait donc briser le verrou, le cas échéant).
la source