Droits d'accès: linux
Une petite tache donné par le prof qui m'a vraiment bloqué dont voila l'énoncé :
" Supposant vous disposer de deux comptes sur votre système
Créez un fichier que votre collègue peut modifier mais pas supprimer et un autre qu’il peut supprimer mais pas modifier " (Fin de l'énoncé)
Peut être que les droits étendues SUID-Bit et SGID-Bit (dont je n'ai rien compris comment et quand les utilisez) font partie de la solution?
Donc:
Qui peut m'aider à résoudre cette exercice avec explication ?
et qui peut m'expliquer les notions SUID-BIT et SGID-Bit théoriquement et pratiquement parlant ?
Merci à vous
" Supposant vous disposer de deux comptes sur votre système
Créez un fichier que votre collègue peut modifier mais pas supprimer et un autre qu’il peut supprimer mais pas modifier " (Fin de l'énoncé)
Peut être que les droits étendues SUID-Bit et SGID-Bit (dont je n'ai rien compris comment et quand les utilisez) font partie de la solution?
Donc:
Qui peut m'aider à résoudre cette exercice avec explication ?
et qui peut m'expliquer les notions SUID-BIT et SGID-Bit théoriquement et pratiquement parlant ?
Merci à vous
A voir également:
- Droits d'accès: linux
- Acces rapide - Guide
- Accès refusé - Guide
- Trousseau d'accès iphone - Guide
- Accès presse papier - Guide
- Je n'ai plus acces a ma boite mail gmail - Guide
1 réponse
Bonjour,
Pré-requis : les droits
Comme tu le sais sûrement, sous linux, chaque fichier a un utilisateur propriétaire, un groupe propriétaire, et un jeu de droits rwx (read/write/execute) qui s'appliquent respectivement à l'utilisateur propriétaire (u), au groupe propriétaire (g), et aux autres utilisateurs (o).
Il en résulte donc trois triplets rwx. Quand tu utilises la commande
Pour plus de détails voir ici :
https://www.mistra.fr/tutoriel-linux-profils-et-droits.html
Le bit SUID
Le bit SUID est expliqué en détail ici.
En bref, il permet à un utilisateur B de bénéficier des droits d'un utilisateur A au moment d'exécuter un programme dont l'utilisateur propriétaire est A. En pratique A est toujours l'utilisateur root.
Exemple : Un cas concret, c'est la commande
Dans le triplet (u), à la place du traditionnel "x" ou "-" on voit un "s". Cela signifie que le bit SUID est activé.
C'est parfaitement normal pour cet exécutable. En effet, un utilisateur peut modifier son propre mot de passe. Pourtant, cette opération modifie
Il va de soi qu'un programme avec un bit SUID doit être écrit avec soin et avoir des droits appropriés pour éviter tout risque d'intrusion. Si par exemple n'importe qui peut en modifier le contenu, il peut très facilement devenir root sur la machine.
Le bit SUID s'active avec la commande
Le bit GUID
Le bit GUID fonctionne sur le même principe, excepté qu'il s'applique au groupe propriétaire. Il est en pratique peu utilisé.
Retour à ton problème
Je ne pense pas que le bit SUID t'aide dans le cas présent. Le bit SUID n'est applicable que si l'utilisateur propriétaire est root, ce qui n'est pas conforme avec les hypothèses de ton problème.
Ici, je pense que la bonne solution consiste à passer par les droits ACL.
Voir les commandes
https://www.mistra.fr/tutoriel-linux-profils-et-droits.html
https://doc.ubuntu-fr.org/acl
Ensuite la distinction entre supprimable et juste modifiable se réalise en configurant les droits adéquats dans le répertoire parent.
https://stackoverflow.com/questions/869536/linux-directory-permissions-read-write-but-not-delete
Bonne chance
Pré-requis : les droits
Comme tu le sais sûrement, sous linux, chaque fichier a un utilisateur propriétaire, un groupe propriétaire, et un jeu de droits rwx (read/write/execute) qui s'appliquent respectivement à l'utilisateur propriétaire (u), au groupe propriétaire (g), et aux autres utilisateurs (o).
Il en résulte donc trois triplets rwx. Quand tu utilises la commande
ls -ltu retrouves toutes ces informations. Si la lettre apparaît, le droit est actif, sinon, si un tiret occupe sa place, le droit est désactivé.
Pour plus de détails voir ici :
https://www.mistra.fr/tutoriel-linux-profils-et-droits.html
Le bit SUID
Le bit SUID est expliqué en détail ici.
En bref, il permet à un utilisateur B de bénéficier des droits d'un utilisateur A au moment d'exécuter un programme dont l'utilisateur propriétaire est A. En pratique A est toujours l'utilisateur root.
Exemple : Un cas concret, c'est la commande
passwd. Si tu regardes où elle est (
which passwd) et que tu regardes ses droits avec
ls -ltu vas voir ça :
(mando@aldur) (~) $ ls -l $(which passwd) -rwsr-xr-x 1 root root 59640 sept. 27 18:45 /usr/bin/passwd
Dans le triplet (u), à la place du traditionnel "x" ou "-" on voit un "s". Cela signifie que le bit SUID est activé.
C'est parfaitement normal pour cet exécutable. En effet, un utilisateur peut modifier son propre mot de passe. Pourtant, cette opération modifie
/etc/shadow. Or ce fichier n'est lisible et modifiable que par
root. En temps normal, un programme lancé par un utilisateur A ne peut modifier que les fichiers sur lesquels A a des droits en écriture. C'est pourquoi le bit SUID est ici nécessaire : il permet à A de bénéficier des droits root pour altérer ce fichier.
Il va de soi qu'un programme avec un bit SUID doit être écrit avec soin et avoir des droits appropriés pour éviter tout risque d'intrusion. Si par exemple n'importe qui peut en modifier le contenu, il peut très facilement devenir root sur la machine.
Le bit SUID s'active avec la commande
chmod.
touch toto.sh sudo chown root toto.sh sudo chmod 4755 toto.sh
Le bit GUID
Le bit GUID fonctionne sur le même principe, excepté qu'il s'applique au groupe propriétaire. Il est en pratique peu utilisé.
chmod 2755 toto.sh
Retour à ton problème
Je ne pense pas que le bit SUID t'aide dans le cas présent. Le bit SUID n'est applicable que si l'utilisateur propriétaire est root, ce qui n'est pas conforme avec les hypothèses de ton problème.
Ici, je pense que la bonne solution consiste à passer par les droits ACL.
Voir les commandes
setfacl,
getfaclet :
https://www.mistra.fr/tutoriel-linux-profils-et-droits.html
https://doc.ubuntu-fr.org/acl
Ensuite la distinction entre supprimable et juste modifiable se réalise en configurant les droits adéquats dans le répertoire parent.
https://stackoverflow.com/questions/869536/linux-directory-permissions-read-write-but-not-delete
Bonne chance