la suppression de l'autorisation d'écriture n'empêche pas la racine d'écrire dans le fichier

Je viens de remarquer sur ma machine Ubuntu (système de fichiers ext3) que la suppression des autorisations d'écriture d'un fichier n'empêche pas root d'y écrire.

S'agit-il d'une règle générale des autorisations de fichiers UNIX? Ou spécifique à Ubuntu? Ou une mauvaise configuration sur ma machine?

# touche abc
# chmod ugo-w abc
# python
Python 2.6.4 (r264: 75706, 7 décembre 2009, 18:45:15) 
[GCC 4.4.1] sur linux2
Tapez "aide", "copyright", "crédits" ou "licence" pour plus d'informations.
>>> open ('abc', 'w'). write ('AAA \ n')
>>> 
# cat abc
AAA

L'écriture dans le fichier échoue (comme prévu) si je le fais à partir de mon compte d'utilisateur normal.

1. Est-ce un comportement normal?

2. Existe-t-il un moyen d'empêcher root d'écrire accidentellement dans un fichier? (Utiliser de préférence des mécanismes de système de fichiers normaux, pas AppArmor, etc.)

S'il vous plaît, apprenez-moi quelque chose que je ne comprends absolument pas.

REMARQUE: je comprends que root a un contrôle total sur le système et peut, par exemple, modifier les autorisations sur n'importe quel fichier. Ma question est de savoir si les autorisations actuellement définies sont appliquées sur le code exécuté en tant que root . L'idée est que l'utilisateur root s'empêche d'écrire accidentellement dans un fichier.

REMARQUE: je comprends également que l' on ne doit pas être connecté en tant que root pour les opérations normales. Je viens de remarquer ce comportement et je vous le demande.

1) Il s'agit d'un comportement normal. root a un accès rw sur tous les fichiers à tout moment.

2) Vous pouvez protéger un fichier même de la racine (pas une action délibérée, mais accidentelle de toute façon) en utilisant

chattr +i filename.ext

C'est "changer les attributs ajouter immuable". Pour retirer la protection:

chattr -i filename.ext

jetez un oeil man chattrpour plus d'informations

1. Oui, c'est normal. La racine est Dieu.

2. Oui, il existe des moyens d'empêcher root de remplacer les fichiers.

   • Définissez le bit immuable avec chattr( +idéfinit, -idésactive). Nécessite un accès root, ne fonctionne que sur ext2 / ext3 (probablement ext4 également), mais est par ailleurs pratique.
   • N'exécutez pas d'applications en tant que root. Pas de privilèges root, pas d'écrasement de fichiers. Utilisez sudopour accéder aux fonctions du système.
   • Démontez le système de fichiers. Pas de fs monté, pas d'écrasement de fichiers. [*]
   • Éteins l'ordinateur. Pas d'électricité, pas d'écrasement de fichiers.

Ces méthodes découlent logiquement du n ° 1. Comme vous pouvez le voir, les deux dernières méthodes ne sont généralement pas utiles, de la même manière que la protection de Windows contre les virus en débranchant le réseau n'est généralement pas utile. C'est pourquoi la racine est dangereuse. [+]

_{[*] Réduire la possibilité d'écrire "accidentellement" directement sur le périphérique de blocage, bien sûr. Oui, root peut le faire. Oui, vous pouvez empêcher cela: déconnectez l'appareil.}

_{[+] C'est aussi de là que viennent ces mythes BOfH. Ce ne sont pas tous des mythes.}

Vous pouvez également restreindre l'accès aux fichiers pour l'utilisateur root, en utilisant les «capacités» du noyau Linux: http://www.securityfocus.com/infocus/1400

Il existe également la possibilité d'utiliser SE-Linux ou un autre correctif du noyau pour rendre certains fichiers immuables, même à la racine.

Je pense que tant que root est le superutilisateur, et qu'il peut tout faire, vous ne pouvez pas lui retirer de permission, même si vous êtes root. C'est censé être la volonté de la racine de s'empêcher de faire ou non une opération (comme écrire dans un fichier, ou ouvrir une application).

Donc non, il est probable que vous ne désactiviez que le compte root, pour éviter une mauvaise utilisation de celui-ci.

Cordialement

[Note à moi-même: vous serez humbles ... peut-être que vous avez tort]