Noob here : chmod, rwx et delete

[Aloyse57]

Bonjour,

Je suis en train de définir des sécurités sur un logiciel et je me suis dit que ce ne serait pas mal de représenter ça à la Unix (rwxrwxrwx). Sauf que du coup j'ai réalisé que ça ne traite pas le cas de la suppression séparément de la modification. Comme je suis certain qu'il y a un mécanisme pour ne pas autoriser la suppression d'un fichier, je me demande à quel endroit c'est configuré ?

Je travaille sous NTFS à 100%, mais j'ai déjà oeuvré sous SCO/AIX (et AS/400) il y a +20 ans...😅

Merci,

 

[Fab'z]

Hello :)

Pour les suppressions sous unix il faut chercher du coté du sticky bit ! t'as aussi le SUID et SGID. Chacun de ses droits spéciaux se positionne sur le paramètre x. C'est assez bien expliqué sur la page wiki.

[Aloyse57]

Merci.

Intéressant de voir que Linux ne gère pas la différence Modify/Delete au niveau fichier...

[Fab'z]

A ba c'est de l'unix tout simple. T'as les ACL par dessus mais c'est plus pour la gestion des droits que pour affiner les permissions. Je sais pas s'il y a d'autre surcouche qui existe pour ça.

 

Ça me fait penser aux produits Office de M$ qui gèrent pas les droits de suppression. Quand on modifie un Word ou un Excel, le fichier est supprimé avant d'être réécrit. Du coup on peut pas utiliser les droits NTFS contre la suppression avec un produit M$...

[L33thium]

Si on peut modifier un fichier on peut supprimer tout son contenu, Donc inutile d'interdire la suppression du fichier dans ce cas.

Une solution peut être le copy on write du système de fichiers comme btrfs. Les fichiers supprimés le sont pas vraiment. Ils sont toujours dans le snapshot RO à la date où il a été pris.

[Fab'z]

C'est un peu la question que je me posais au niveau des systèmes de fichiers... est-ce que la modification existe vraiment ? Est-ce que ce ne sont pas des réécriture complète avec des inodes/indexes différents ? 🤔

[L33thium]

En COW l'intégralité du fichier est dupliqué suite à sa modification. Sinon non, en dehors de cette pratique, je ne sais pas exactement si le système va aller modifier directement les bytes concernés, sinon c'est une copie et réécriture de "clusters" (si cette notion existe encore) mais pas une copie complète (imagine l'enfer des bases de données de plusieurs Go sinon).

[brice.wernet]

Le rwx de Unix, c'est le niveau 0 des années 70. Sous indows, ça correspond aux attributs AR de DOS (plus utilisés, sinon on ne serait pas bêtes et on utiliserait correctement l'attribut A qui est super pratique en vrai).

Sinon, on met des ACL comme sous Windows.

[L33thium]

Les permissions POSIX sont la base et c'est suffisant pour les usages les plus courants, ils peuvent être étendus par les ACL et les attributs.

Linux et les Unix obéissent souvent à la règle KISS.
Et on aime pas trop faire de choses inutiles (comme le fait que je ne vois pas à quoi sers d'interdire la suppression d'un fichier si on peut modifier son contenu, donc le vider ou y mettre des données farfelues).

Il faut que ça reste souple et capable d'être simple (on peux toujours faire un OS de quelques dizaines de Mo comme un système beaucoup plus complexe avec les même briques de base).

[ashlol]

Il y a 30 minutes, L33thium a écrit :

je ne vois pas à quoi sers d'interdire la suppression d'un fichier si on peut modifier son contenu, donc le vider ou y mettre des données farfelues).

l'intérêt simple et immédiat c'est de savoir que ce fichier a été vidé et quand alors que une fois delete il n'existe plus donc "aucune trace" c'est bien pour cela qu'il existe des softs qui interdisent le delete pour justement pouvoir garder un historique de la traçabilité ce qui est le plus important en pro qui suivent des normes de qualité...

[ecatomb]

Sous unix, les droits de suppression d'un fichier sont dans le répertoire. C'est comme un annuaire avec la liste des fichiers à afficher 😁

[L33thium]

Il y a 6 heures, ecatomb a écrit :

Sous unix, les droits de suppression d'un fichier sont dans le répertoire. C'est comme un annuaire avec la liste des fichiers à afficher 😁

A merde j'avais oublié ça c'est très con ^^ mais oui on peut tout à fait avoir des fichier RW dans un dossier RO.
Comme le listing des fichiers est interdit si on retire le droit x au dossier alors que l'accès aux fichiers à l'intérieur est toujours possible en pointant directement dessus

[lorinc]

On 18/03/2021 at 11:20, ecatomb a écrit :

Sous unix, les droits de suppression d'un fichier sont dans le répertoire. C'est comme un annuaire avec la liste des fichiers à afficher 😁

De mémoire, c'est plus compliqué que ça, mais en résumé, oui. Au niveau du fs, le syscall est unlink et prend en argument l'inode du fichier et sa dentry. la modification de l'inode se fait carrément au niveau du fs, pas du fichier ni du répertoire. Par contre, si c'est le dernier lien, alors la dentry est aussi supprimée. Mais les dentry sont stockées dans la partie data du répertoire parent. Donc pour supprimer la dentry, il faut pouvoir modifier les data du répertoire parent, donc avoir les droits dessus.

[L33thium]

j'ai vérifié pour ma culture personnelle :

~/test$ mkdir pouet
~/test$ touch pouet/prout
~/test$ chmod -w pouet
~/test$ touch pouet/proutprout
touch: impossible de faire un touch 'pouet/proutprout': Permission non accordée
~/test$ echo "ok" > pouet/prout
~/test$ rm pouet/prout
rm: impossible de supprimer 'pouet/prout': Permission non accordée
~/test$ cat pouet/prout
ok

 

[ecatomb]

chmod -x pouet
echo "ok" > pouet/prout

Test ceci 😉

C'est assez surprenant que le "touch" ne marche plus mais que le "echo" fonctionne toujours pour la création d'un fichier dans ton cas. Vive la redirection 😁

 

Une réponse intéressante sur ces droits 

directory - In Linux, is "write" permission equivalent to "execute" for directories? - Unix & Linux Stack Exchange

[L33thium]

j'ai passé le -w après la création du fichier.
Le deuxième touch c'est pour tenter de créer un nouveau fichier proutprout, prout existe déjà
De mémoire le -x sur un dossier empêche le listing de son contenu mais pas l'accès aux fichiers si le nom est connu

[ecatomb]

Ah oui, suis-je bête... Le fichier existe suite au touch, donc pas besoin des droits d'écriture dans le répertoire pour que le echo fonctionne. C'est les droits d'écriture du fichier : classique