sym-links root effaçables par $USER : normal ? [ résolu : oui ]

Coeur Noir · Le 14/04/2020, à 02:34

Hello,

Dans un /home/$USER ( dans la / sur un SSD ) j'ai créé des liens symboliques vers des dossiers sur une partition d'un autre disque ( HDD ) via

sudo ln -s /media/DATA/un_dossier /home/$USER/un_dossier

Les dossiers ( et fichiers ) sur cet autre partition appartiennent à ce même $USER.

depuis la session $USER aucun souci pour y accéder, écrire, manipuler, etc.

Par contre à ma grande surprise le $USER peut tout à fait supprimer ce lien un_dossier ( ce qui n'efface pas la source ).
Je croyais vraiment qu'en créant ce lien via sudo, seul root pourrait le supprimer ( ce qui me serait tout à fait convenu ).

Qu'en pensez-vous ?

Ubuntu Budgie 19.10 ici, donc Nemo en explorateur de fichiers par défaut.

Exemple d'un /home/$USER :

django@ASGARD:~$ ls -l
total 8
lrwxrwxrwx  1 root   root     29 avril 10 23:25 Bureau -> /media/DATA/coeurnoir/Bureau/
lrwxrwxrwx  1 root   root     32 avril 11 18:32 Documents -> /media/DATA/coeurnoir/Documents/
lrwxrwxrwx  1 root   root     29 avril 10 23:14 Images -> /media/DATA/coeurnoir/Images/
drwxrwxr-x 11 django django 4096 avril 13 02:10 Logiciels
lrwxrwxrwx  1 django django   30 avril 11 16:54 Modèles -> /media/DATA/coeurnoir/Modèles
lrwxrwxrwx  1 root   root     49 avril 10 23:14 Musique -> '/media/DATA/Bibliothèque Musicale/Bibliothèque/'
drwxrwxr-x  5 django django 4096 avril 10 19:42 snap
lrwxrwxrwx  1 django django   39 avril 11 16:55 Téléchargements -> /media/DATA/coeurnoir/Téléchargements
lrwxrwxrwx  1 root   root     30 avril 10 23:14 Vidéos -> /media/DATA/coeurnoir/Vidéos/
django@ASGARD:~$

…les liens qui ne sont plus root sont ceux que j'ai recréés après avoir constaté que je pouvais les effacer depuis Nemo dans la session django.

Et la même pour montrer les sources :

django@ASGARD:/media/DATA/coeurnoir$ ls -l
total 28
drwxrwsr-x 2 django maison 4096 avril 13 22:19 Bureau
drwxrwsr-x 4 django maison 4096 avril 12 01:46 Documents
drwxrwsr-x 9 django maison 4096 avril 11 19:18 Images
drwxrwsr-x 2 django maison 4096 avril 11 16:54 Modèles
drwxrwsr-x 2 django maison 4096 avril 12 01:43 Téléchargements
drwxrwsr-x 4 django maison 4096 avril 12 01:47 Vidéos
django@ASGARD:/media/DATA/coeurnoir$

Et question bonus, via ls peut-on afficher les id et gid sous forme numérique plutôt qu'en toutes lettres ? → réponse : oui avec ls -n

Dernière modification par Coeur Noir (Le 15/04/2020, à 00:27)

LukePerp · Le 14/04/2020, à 07:38

Tout est dans la permission du lien :

lrwxrwxrwx ........

xinu · Le 14/04/2020, à 08:01

Bonjour,

En effet, les permissions affichées ne sont pas utilisées. Le lien hérite d'office des permissions et droits dont bénéficie le fichier cible.

kamaris · Le 14/04/2020, à 16:53

Coeur Noir a écrit :

Par contre à ma grande surprise le $USER peut tout à fait supprimer ce lien un_dossier ( ce qui n'efface pas la source ).
Je croyais vraiment qu'en créant ce lien via sudo, seul root pourrait le supprimer ( ce qui me serait tout à fait convenu ).

La possibilité de supprimer ou non un fichier n'est pas liée aux permissions de ce fichier, mais à celles du répertoire qui le contient.
Si root crée un fichier dans ton home, qu'il s'agisse d'un lien symbolique ou autre, tu pourras toujours le supprimer, car le répertoire en question t'appartient.

Coeur Noir · Le 14/04/2020, à 20:38

@lukeperp, @xlnu : ok ça m'éclaire, merci !

@kamaris Si root crée un fichier dans ton home, qu'il s'agisse d'un lien symbolique ou autre, tu pourras toujours le supprimer, car le répertoire en question t'appartient.
Donc parce que mon $USER a les droits d'écriture sur le répertoire parent, il peut effacer des trucs qui ne lui appartiennent pas / qui appartiennent à root.
Ça, ça ne me parait pas logique mais oui tu as raison c'est bien ce que je constate ; j'ai cru que c'était du à l'appartenance au groupe maison via bit sgid, mais non :
⋅
⋅ dans les 2 cas je peux effacer le fichier test
⋅ par contre dans les 2 cas, si je veux modifier le fichier dans gedit, il m'indique bien lecture seule tant que je ne passe pas gedit admin:///home/django/Documents/test
→ vous pouvez vous moquer de moi car je viens de découvrir l'eau tiède , mais je ne comprends pas cette différence entre modifier/écrire/supprimer…

Ça m'amène par conséquent à une autre question : comment je peux protéger des liens d'un effacement ?
Car ce serait insensé que j'enlève tout droit d'écriture sur les sources, ça empêcherait les utilisateurs d'avoir un usage « normal » de ces dossiers.

Dernière modification par Coeur Noir (Le 14/04/2020, à 20:39)

lynn · Le 14/04/2020, à 21:12

Bonjour,

Pour empêcher la suppression d'un fichier

sudo chattr +i fichier

et pour lui remettre la possibilité d'être supprimé

sudo chattr -i fichier

kamaris · Le 14/04/2020, à 21:14

Eh bien simplement, les droits de création / suppression de fichiers sont gérés au niveau du répertoire contenant, pas au niveau du fichier.
La logique si on veut, c'est que créer ou supprimer un fichier, c'est écrire dans le répertoire, vu comme un fichier.
Ainsi, si les utilisateurs n'ont pas les droits d'écriture dans le répertoire, ils ne pourront ni créer ni supprimer de fichiers, mais ils pourront par contre modifier les fichiers qu'il contient (à condition d'en avoir les droits au niveau de ces fichiers).
Maintenant, si tu veux protéger un lien d'une suppression tout en laissant les droits d'écriture au niveau du répertoire contenant, une possibilité est de rendre le lien « immuable » (immutable) par chattr +i.

EDIT : grillé pour la fin

Dernière modification par kamaris (Le 14/04/2020, à 21:18)

Coeur Noir · Le 14/04/2020, à 21:26

Vous êtes merveilleux !

Alors la bonne logique c'est quoi, agir sur le dossier source :

sudo chattr +i /media/DATA/machin/le_dossier

ou

sudo chattr +i /home/machin/le_dossier

qui est dans ce second cas le lien ?

ou les deux mon capitaine ?
Du côté de chaque utilisateur individuel j'empêche qu'il supprime les liens lui donnant accès à ses affaires
et côté stockage, j'empêche d'effacer par mégarde les sources utiles aux liens des divers utilisateurs.

Arrfff, bah non uniquement sur les liens si je comprends bien :

http://manpages.ubuntu.com/manpages/trusty/fr/man1/chattr.1.html a écrit :

Un fichier avec l'attribut « i » ne peut pas être modifié : il ne peut pas être supprimé
ou renommé, aucun lien ne peut être fait vers lui et on ne peut pas y écrire de données.
Seul le superutilisateur ou un processus avec la capacité CAP_LINUX_IMMUTABLE peut ajouter
ou retirer cet attribut.

Dernière modification par Coeur Noir (Le 14/04/2020, à 21:39)

kamaris · Le 14/04/2020, à 21:38

Avec un lien symbolique ça ne fonctionnera pas, il faut un lien normal, auquel cas l'action sur la source ou le lien revient au même.

lynn · Le 14/04/2020, à 21:38

Pour une information complémentaire, la commande chattr +/- i n'agit pas sur les liens symboliques... seulement sur les fichiers ou dossiers.

Grillée !

Dernière modification par lynn (Le 14/04/2020, à 21:39)

kamaris · Le 14/04/2020, à 21:41

Vengeance !

Coeur Noir · Le 14/04/2020, à 21:42

Oh misère… Et c'est quoi un lien « normal » par rapport à un lien symbolique ? hard link ?

kamaris · Le 14/04/2020, à 21:50

Oui c'est ça, hard link (pas sûr que « lien normal » soit très employé…)
Pour info aussi, c'est justement un hard link qu'on ne peut pas faire depuis un fichier avec l'attribut immutable, mais on peut faire un lien symbolique (car il n'a aucun lien physique avec le fichier qu'il désigne).

lynn · Le 14/04/2020, à 21:56

Quelques infos complémentaires ici.

Coeur Noir · Le 14/04/2020, à 23:16

Un hard link peut être immutable mais

https://doc.ubuntu-fr.org/lien_physique_et_symbolique a écrit :

Lien physique : (…) Contrairement aux liens symboliques, ils ne peuvent pointer que vers un autre élément du même système de fichiers.

…d'où autre question, 2 partitions différentes, sur 2 disques distincts, déclarés dans fstab ça compte pour un seul système de fichiers ou pas ? Je dirais non, ce sont 2 racines de 2 système de fichiers différents…

Et apparemment, avant même la question du même système de fichiers :

django@ASGARD:~$ ln /media/DATA/coeurnoir/Documents/ lien
ln: /media/DATA/coeurnoir/Documents/ : lien direct non permis pour un répertoire

Et d'un autre côté si je rends immutable le dossier source d'un lien ( symbolique ), cette source n'est plus modifiable.

Conclusion : j'oublie l'idée de vouloir « protéger » ces liens symboliques - les données sources n'étant pas impactées par l'effacement d'un tel lien.

Dernière modification par Coeur Noir (Le 15/04/2020, à 00:28)

kamaris · Le 14/04/2020, à 23:41

Coeur Noir a écrit :

…d'où autre question, 2 partitions différentes, sur 2 disques distincts, déclarés dans fstab ça compte pour un seul système de fichiers ou pas ? Je dirais non, ce sont 2 racines de 2 système de fichiers différents…

Normalement non…
Au pire tu peux créer un répertoire avec l'attribut immutable, dans lequel tu mets un lien symbolique vers là où tu veux : c'est moche, mais bon…
Non seulement c'est moche, assez inutile, mais ça ne fonctionnera pas : il n'est pas plus possible de placer l'attribut immutable sur un répertoire que sur un lien symbolique.

Dernière modification par kamaris (Le 15/04/2020, à 11:10)

Coeur Noir · Le 15/04/2020, à 00:26

Ça ne fait que « déplacer » le ( petit ) risque.

La question initiale ayant trouvé réponse grâce à vos lumineuses interventions, je passe en résolu !

kamaris · Le 15/04/2020, à 22:08

Une solution, tirée de https://unix.stackexchange.com/a/20106 :

sudo chown root:user /home/user
sudo chmod 1775 /home/user
sudo ln -s /répertoire-à-lier /home/user/lien
sudo chown -h root:user /home/user/lien # optionnel si le lien a bien été créé par root, nécessaire sinon

Normalement, après ça :

$ rm lien
rm: impossible de supprimer 'lien': Opération non permise
$

Coeur Noir · Le 15/04/2020, à 23:21

Je testerai. Même si je suppose que là, l'user ne pourra plus créer de nouveau dossier dans /home/user… quoi que… puisque le groupe a les droits rwX…

…passionnant !

xinu · Le 15/04/2020, à 23:21

Bonsoir,

@kamaris, juste par curiosité, les commandes que tu donnes en #18, tu les a vraiment exécutées ? Tu as vu ceci :

Different OS behave differently with sticky bits as explained in this wikipedia article. For example, Linux only looks for sticky bit if a user tries to rename a file. It will not check the sticky bit if a file is being deleted.

Source : https://www.thegeekstuff.com/2013/02/sticky-bit/

Amicalement.

kamaris · Le 15/04/2020, à 23:52

Coeur Noir a écrit :

Je testerai. Même si je suppose que là, l'user ne pourra plus créer de nouveau dossier dans /home/user… quoi que… puisque le groupe a les droits rwX…

Si si, de la même façon qu'il peut créer tout ce qu'il veut dans /tmp.

xinu a écrit :

@kamaris, juste par curiosité, les commandes que tu donnes en #18, tu les a vraiment exécutées ?

Oui
Sauf exception avec mention explicite, je teste ce que je propose.

xinu a écrit :

Tu as vu ceci :
Different OS behave differently with sticky bits as explained in this wikipedia article. For example, Linux only looks for sticky bit if a user tries to rename a file. It will not check the sticky bit if a file is being deleted.
Source : https://www.thegeekstuff.com/2013/02/sticky-bit/

Les blogs ne sont pas des sources sûres, d'ailleurs la page wikipédia citée ne dit pas ça.
Voici man chmod chez moi :

man chmod a écrit :

RESTRICTED DELETION FLAG OR STICKY BIT
The restricted deletion flag or sticky bit is a single bit, whose interpretation depends on the file type. For directories, it prevents unprivileged users from removing or
renaming a file in the directory unless they own the file or the directory; this is called the restricted deletion flag for the directory, and is commonly found on world-
writable directories like /tmp. For regular files on some older systems, the bit saves the program's text image on the swap device so it will load more quickly when run;
this is called the sticky bit.

Comme il est dit (ici et dans wikipédia), c'est le comportement typique de /tmp : tu ne peux pas supprimer (ou renommer) ce qui ne t'appartient pas.

xinu · Le 16/04/2020, à 00:08

#kamaris, merci

RESTRICTED DELETION FLAG OR STICKY BIT
The restricted deletion flag or sticky bit is a single bit, whose interpretation depends on the file type. For directories, it prevents unprivileged users from removing or renaming a file in the directory unless they own the file or the directory

Ça a le mérite d'être clair et solutionne mon problème.

A+

Dernière modification par xinu (Le 16/04/2020, à 00:10)

Coeur Noir · Le 16/04/2020, à 01:33

Heu…

django@ASGARD:/home$ ls -l
total 12
drwxrwxr-x 12 alessandra alessandra 4096 avril 15 22:54 alessandra
drwxrwsr-x 13 cinema     cinema     4096 avril 15 22:58 cinema
drwxrwxr-x 19 root       django     4096 avril 16 01:25 django
django@ASGARD:/home$ cd django
django@ASGARD:~$ ls -l
total 8
lrwxrwxrwx  1 root   django   29 avril 10 23:25 Bureau -> /media/DATA/coeurnoir/Bureau/
lrwxrwxrwx  1 root   django   32 avril 11 18:32 Documents -> /media/DATA/coeurnoir/Documents/
lrwxrwxrwx  1 root   django   29 avril 10 23:14 Images -> /media/DATA/coeurnoir/Images/
drwxrwxr-x 11 django django 4096 avril 13 02:10 Logiciels
lrwxrwxrwx  1 root   django   30 avril 11 16:54 Modèles -> /media/DATA/coeurnoir/Modèles
lrwxrwxrwx  1 root   django   49 avril 10 23:14 Musique -> '/media/DATA/Bibliothèque Musicale/Bibliothèque/'
drwxrwxr-x  5 django django 4096 avril 10 19:42 snap
lrwxrwxrwx  1 root   django   39 avril 11 16:55 Téléchargements -> /media/DATA/coeurnoir/Téléchargements
lrwxrwxrwx  1 root   django   30 avril 10 23:14 Vidéos -> /media/DATA/coeurnoir/Vidéos/
django@ASGARD:~$ rm Documents
django@ASGARD:~$

…j'ai oublié quoi ?
Parce que là, le user django il efface sans problème → c'est à cause du bit sgid du côté sources des liens ?
[ je me passerais volontiers du bit sgid si le umask que je définis à 002 dans /etc/login.defs était bien suivi par toutes les appli's… ]

J'ajoute ce qui concerne les sources des liens :

django@ASGARD:/media/DATA$ ls -l
total 36
drwxrwsr-x  9 alessandra maison  4096 avril 12 00:51  alessandra
drwxrwsr-x  4 root       maison  4096 avril 12 00:52 'Bibliothèque Musicale'
drwxrwsr-x  9 django     maison  4096 avril 14 02:26  coeurnoir
drwxrwsr-x 10 cinema     cinema  4096 avril 15 18:08  gdpalace
drwx------  2 root       root   16384 déc.  25  2013  lost+found
drwxr-xr-x  5 root       root    4096 avril  9 20:39  thunderbird
django@ASGARD:/media/DATA$ cd coeurnoir/
django@ASGARD:/media/DATA/coeurnoir$ ls -l
total 28
drwxrwsr-x 3 django maison 4096 avril 16 01:25 Bureau
drwxrwsr-x 4 django maison 4096 avril 14 20:37 Documents
drwxrwsr-x 9 django maison 4096 avril 11 19:18 Images
drwxrwsr-x 2 django maison 4096 avril 11 16:54 Modèles
drwxrwsr-x 4 django maison 4096 avril 11 23:51 old_thunderbird
drwxrwsr-x 2 django maison 4096 avril 12 01:43 Téléchargements
drwxrwsr-x 4 django maison 4096 avril 12 01:47 Vidéos
django@ASGARD:/media/DATA/coeurnoir$

et juste par curiosité

django@ASGARD:/$ ls -l
total 76
(…)
drwxrwxrwt  19 root root  4096 avril 16 02:10 tmp
(…)
django@ASGARD:/$

→ drwxrwxrwt du coup, qu'est-ce qu'on ne peut pas faire dans /tmp ? Parce que là à première vue il a l'air à poil, le pauvre…

Dernière modification par Coeur Noir (Le 16/04/2020, à 03:05)

kamaris · Le 16/04/2020, à 09:35

Tu n'as pas mis le sticky bit sur /home/django :

drwxrwxr-x 19 root       django     4096 avril 16 01:25 django

Il manque le t à la fin, donc il devait manquer le 1 au début de ta commande chmod :

sudo chmod 1775 /home/django

NB : dans /tmp, tu ne peux pas supprimer ou renommer ce qui ne t'appartient pas.
Donc par exemple, si django crée un fichier dans /tmp, alessandra ne pourra pas le supprimer ou le renommer, et inversement.

Dernière modification par kamaris (Le 16/04/2020, à 09:38)

Coeur Noir · Le 16/04/2020, à 18:25

Rrrrôôôooo… bah oui !

( alors qu'après je vois bien le t concernant /tmp … )

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 14/04/2020, à 02:34

sym-links root effaçables par $USER : normal ? [ résolu : oui ]

#2 Le 14/04/2020, à 07:38

Re : sym-links root effaçables par $USER : normal ? [ résolu : oui ]

#3 Le 14/04/2020, à 08:01

Re : sym-links root effaçables par $USER : normal ? [ résolu : oui ]

#4 Le 14/04/2020, à 16:53

Re : sym-links root effaçables par $USER : normal ? [ résolu : oui ]

#5 Le 14/04/2020, à 20:38

Re : sym-links root effaçables par $USER : normal ? [ résolu : oui ]

#6 Le 14/04/2020, à 21:12

Re : sym-links root effaçables par $USER : normal ? [ résolu : oui ]

#7 Le 14/04/2020, à 21:14

Re : sym-links root effaçables par $USER : normal ? [ résolu : oui ]

#8 Le 14/04/2020, à 21:26

Re : sym-links root effaçables par $USER : normal ? [ résolu : oui ]

#9 Le 14/04/2020, à 21:38

Re : sym-links root effaçables par $USER : normal ? [ résolu : oui ]

#10 Le 14/04/2020, à 21:38

Re : sym-links root effaçables par $USER : normal ? [ résolu : oui ]

#11 Le 14/04/2020, à 21:41

Re : sym-links root effaçables par $USER : normal ? [ résolu : oui ]

#12 Le 14/04/2020, à 21:42

Re : sym-links root effaçables par $USER : normal ? [ résolu : oui ]

#13 Le 14/04/2020, à 21:50

Re : sym-links root effaçables par $USER : normal ? [ résolu : oui ]

#14 Le 14/04/2020, à 21:56

Re : sym-links root effaçables par $USER : normal ? [ résolu : oui ]

#15 Le 14/04/2020, à 23:16

Re : sym-links root effaçables par $USER : normal ? [ résolu : oui ]

#16 Le 14/04/2020, à 23:41

Re : sym-links root effaçables par $USER : normal ? [ résolu : oui ]

#17 Le 15/04/2020, à 00:26

Re : sym-links root effaçables par $USER : normal ? [ résolu : oui ]

#18 Le 15/04/2020, à 22:08

Re : sym-links root effaçables par $USER : normal ? [ résolu : oui ]

#19 Le 15/04/2020, à 23:21

Re : sym-links root effaçables par $USER : normal ? [ résolu : oui ]

#20 Le 15/04/2020, à 23:21

Re : sym-links root effaçables par $USER : normal ? [ résolu : oui ]

#21 Le 15/04/2020, à 23:52

Re : sym-links root effaçables par $USER : normal ? [ résolu : oui ]

#22 Le 16/04/2020, à 00:08

Re : sym-links root effaçables par $USER : normal ? [ résolu : oui ]

#23 Le 16/04/2020, à 01:33

Re : sym-links root effaçables par $USER : normal ? [ résolu : oui ]

#24 Le 16/04/2020, à 09:35

Re : sym-links root effaçables par $USER : normal ? [ résolu : oui ]

#25 Le 16/04/2020, à 18:25

Re : sym-links root effaçables par $USER : normal ? [ résolu : oui ]

Pied de page des forums