mot de passe indépendant pour les enfants [RESOLU]

goliath60 · Le 13/10/2022, à 15:28

pour répondre à iznobe (post 47):

vadee@vadee:~$ groups enfants
enfants : enfants vadee
vadee@vadee:~$

goliath60 · Le 13/10/2022, à 15:33

pour répondre à Coeur Noir ( post 49):

Le compte vadee est bien administrateur alors que le compte enfant n'y est pas (décoché)

goliath60 · Le 13/10/2022, à 15:34

pour Geole (post 50):

vadee@vadee:~$ cat /etc/lsb*
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.5 LTS"
vadee@vadee:~$

goliath60 · Le 13/10/2022, à 15:39

je pense avoir répondu à tout le monde,

je vous REMERCIE tous pour votre aide, vos conseils et votre patience.

Arbiel · Le 13/10/2022, à 16:34

Bonjour à tous

Constatant que vous étiez plusieurs, et beaucoup plus expérimentés que moi, à vous pencher sur la difficulté soulevée par goliath60, je n'ai pas jugé utile de revenir mettre mon grain de sel pour élaborer la solution à laquelle vous êtes parvenus, tout en suivant la conversation de loin en loin.

@Coeur Noir
Je te remercie d'avoir voulu rester poli. «curieuse» n'est donc pas le qualificatif que tu jugeais le plus approprié.

Je comprends avoir fait trois erreurs :

1) ne pas avoir demandé à goliath60 de donner le résultat de la commande "ls -l /home", qui aurait mis en évidence que les utilisateurs ne se nommaient ni parents, ni enfants
2) au #8, d'avoir conseillé la commande chmod a+x objet au lieu de chmod a+wx objet
3) mais surtout de ne pas avoir compris qu'il suffisait de proposer à goliath60 de voir les deux mots de passe qu'il avait définis comme un mot de passe public et un mot de passe privé, et de basculer en mode administrateur de l'un à l'autre en début et fin de période ouverte aux enfants, de manière éventuellement automatique avec cron.

Arbiel

goliath60 · Le 13/10/2022, à 16:55

je ne dirais pas "erreur".
En tout cas, je trouve que c'est aussi le but (ou risque) d’écrire sur un forum, d'exposer un problème de devoir trouver une solution avec le peu d'élément que l'on se transmet et si besoin, que le plus sachant aide le moins sachant. C'est un échange de connaissances
il est vrai que les discussions ont été complètes voire contradictoires, et pour ma part, je l'avoue, c'était à plusieurs reprises, une discussion en langue étrangère.
tu fais parti de ceux que je remercie de m'avoir aidé.

A une prochaine

Coeur Noir · Le 13/10/2022, à 18:12

Non la « grosse » erreur me semble le lien symbolique /home/B ciblant /home/A ; ça me paraît curieux comme idée puisque :
⋅ un $HOME est censé appartenir à son titulaire, or le lien symbolique /home/B « transférera » les attributs de /home/A ( donc ce simili /home/B n'appartient pas à B, il appartient à A ),
⋅ la session graphique B a besoin que certains éléments cachés dans son $HOME appartiennent impérativement à B pour bien fonctionner, voire se lancer tout court
⋅ et avec les modes par défaut des $HOME sous 22.04, B n'a de toute façon pas accès au $HOME de A ( on est en 20.04 chez Goliath60 où les $HOME sont encore en 755 lecture pour les autres, ils sont en 750 aucun droit pour les autres sous 22.04 ).

1) on pouvait pas deviner → moralité il faut toujours s'assurer du contexte « techniquement » avec des retours de commandes neutres,
2) c'est pas comme ça qu'on gère les accès / droits,
3) tu te compliques inutilement la vie ;-)

Le plus simple c'est bien d'avoir 2 sessions distinctes, chacune avec son mot de passe, l'une A de type administrateur ( possibilité de sudo pour cet utilisateur ) l'autre B de type normal ( pas de sudo pour l'utilisateur B ), chacune avec son $HOME distinct sous forme de dossier « normal » ( pas de lien symbolique à ce niveau. ) De cette façon seul l'utilisateur A peut lancer des commandes avec les mêmes droits que root pour administrer le système, B ne pourra pas. Et les utilitaires graphiques d'administration système - qu'ils soient lancés par A ou B - demanderont le mot de passe du seul utilisateur administrateur A pour agir, mot de passe que B ne connaît pas. Et ne doit pas connaître !

Ensuite c'est en gérant les propriétaires d'un élément qu'on règle qui accède à quoi. Si B fait partie du groupe de A, il a accès en lecture à /home/A puisque ce dossier est en 750 ( ou 755 ) c.à.d ce dossier donne aux membres du groupe les droits lecture+exécution r-x ; les fichiers eux seront en lecture seule r-- : l'exécution n'est nécessaire que sur des fichiers spécifiques : programmes, scripts… qui seront lancés directement. Elle ne sert à rien sur des « documents et médias » qui seront ouverts à travers d'autres applications ( qui, elles, « exécutent » ).

Un dossier a au minimum des droits r-x → la lecture permet de voir ce dossier, l'exécution permet de rentrer dans le dossier ( l'ouvrir. ) Qu'il manque l'un ou l'autre, le dossier n'est plus utilisable ( en interface graphique du moins. ) Si on ajoute le droit d'écriture rwx à un dossier, on peut alors écrire ( modifier, supprimer ) dedans.

Enfin c'est en modifiant les droits sur un élément qu'on donne plus ou moins d'actions possibles à l'utilisateur de cet élément. Seul l'utilisateur propriétaire d'un élément pourra lui-même en changer les droits. Les actions possibles sont réparties à l'attention de 3 catégories d'utilisateurs : d'abord les 2 propriétaires de l'élément, un utilisateur et un groupe puis les autres ( le reste du monde, les pas-propriétaires de l'élément ).
Par exemple 664 signifie rw-rw-r-- soit lecture+écriture pour l'utilisateur et le groupe propriétaires, lecture seule pour les autres.

Et à partir de là, on peut mettre en place beaucoup de combinaisons, sachant que B est membre du groupe A :
⋅ passer le mode de /home/A/Documents à 770 → donne à B la possibilité d'écrire dans ce dossier ;
⋅ passer le mode de /home/A/Images à 700 → interdit à B de voir ce dossier et d'y entrer, naviguer ( il ne verra rien de ce qui se trouve dedans, même s'il y avait là des éléments qui lui appartiennent. )

Si on ajoute l'utilisateur A au groupe B :
⋅ passer le mode de /home/B à 770 → permet à A d'écrire, modifier, supprimer dans tout le $HOME de B
⋅ etc, etc.

D'autres subtilités existent en plus des droits read, write ou execute : notamment le bit sgid et le sticky bit qui seront utiles en cas de partage de dossier en lecture+écriture entre membres d'un groupe.

Sous Linux, les propriétaires et droits sont des attributs des éléments ( fichier, dossier ). Ils sont portés par les éléments eux-mêmes, inscrits dans les inode du système de fichiers, nativement.

Dernière modification par Coeur Noir (Le 14/10/2022, à 00:17)

Arbiel · Le 13/10/2022, à 19:39

Bonsoir

Je comprends parfaitement ce que tu écris, et avec lequel je suis d'accord (pour ce qui concerne bit sgid et le sticky bit, je n'ai aucune connaissance de la manière ni de les gérer, ni de les utiliser).

Cependant, la demande initiale de goliath60 n'était pas de réduire quelque droit que ce soit pour ses enfants. Je n'avais pas compris qu'il voulait uniquement réduire la période pendant laquelle ses enfants pouvaient utiliser l'ordinateur familial, et cela sans aucune restriction fonctionnelle.Dans ma première intervention, je n'ai envisagé que la solution avec deux utilisateurs et la gestion du groupe parents pour permettre aux enfants d'utiliser toutes les ressources disponibles.

Lorsqu'il a indiqué ne pas savoir gérer les groupes utilisateurs, j'ai essayé de trouver plus simple et je me suis appuyé sur une solution que j'applique pour mon propre compte, dans un contexte certes différent. Arbiel n'es pas mon prénom. Cependant lors de l'installation de mon système actuel, c'est le prénom que je ne suis donné en tant qu'utilisateur, afin de faire correspondre les retours de commandes que je peux être conduit à publier sur le forum, avec ma signature, alors que dans ma précédente installation, je m'étais «correctement» nommé en tant qu'utilisateur.

Je me suis ainsi retrouvé, pour certains fichiers dans lesquels ~ n'est pas accessible (par exemple des lanceurs) avec des références à des dossiers dont le nom est dérivé de mon prénom, et qui, de ce fait, n'existaient plus. J'ai alors créé un répertoire dans /home avec mon prénom effectif, et je l'ai renvoyé sur /home/arbiel.

Pour en revenir au problème posé par goliath60, je pense qu'il y a encore plus simple. Il me semble qu'il suffit d'un seul mot de passe, et de démarrer sans demander le mot de passe pendant la période ouverte aux enfants, et de le demander le reste du temps. Je suppose qu'il existe une commande qui permet de basculer entre ces deux modes de démarrage, mais je ne la connais pas. Et à cela, je n'ai pensé que ce soir.

Cordialement

Arbiel

Dernière modification par Arbiel (Le 13/10/2022, à 19:41)

Coeur Noir · Le 13/10/2022, à 20:20

Mmm… la demande initiale :

il n'y a qu'un seul ordinateur fixe, pour toute la famille.
il n'y "avait" pas de mot de passe.
je souhaiterai un MDP existe pour utiliser l'ordinateur.
j'ai donc mis un MDP sur l'utilisateur principal, qui est le même que celui pour installer ou modifier des paramètres.
Suite à ça, j'ai créé un compte pour les enfants, avec un pot de passe différent du principal. Le problème c'est qu'ils n'ont pas accès aux informations (documents, favoris internet, etc...), c'est un monde à part.
ce que je souhaiterai, pour accéder à l'ordinateur:
avoir un MDP "parents" qui sera en mode administrateur et avoir un MDP "enfant", qui sera en mode "non administrateur" et qui arrivera sur le même bureau, même documents, même internet etc..., juste des MDP différents pour accéder.

Ce qui se résout avec :
⋅ 2 sessions, une en admin l'autre pas, chacune avec un mot de passe ( elles sont déjà en place. )
⋅ ajout des utilisateurs aux groupes l'un de l'autre ( solutionne « ils n'ont pas accès aux informations » )
⋅ l'ajout de l'écriture pour le groupe sur le $HOME enfants n'était pas dans la demande mais me paraissait prudent ( pour permettre à parents~vadee d'intervenir par là, si besoin. )
⋅ mise en place de signets dans les explorateurs de fichiers vers les $HOME de l'un l'autre ( plutôt que des liens symboliques ) ça ne correspond pas tout à fait à la demande mais c'est beaucoup plus simple à mettre en œuvre, sans exclure la possibilité à enfants d'avoir ses propres dossiers usuels ( auxquels parents a accès, en écriture, y'avait pas de hasard dans cette démarche ).
⋅ enfants peut ( tout ) lire dans le $HOME de vadee mais pas y écrire ( histoire qu'enfant n'y supprime rien. )

Mais oui on aurait aussi pu remplacer dans le $HOME de enfants les dossiers usuels Bureau, Documents, Images, etc… par des liens symboliques ciblant les dossiers équivalents dans le $HOME de vadee,
je pensais le proposer au début, mais j'ai préféré raccourcir pour simplifier les manipulations : ça aurait impliqué une gestion plus fine des droits et permissions sur les dossiers usuels de vadee et ses sous-dossiers par ex. pour enlever à la vue de enfants certains éléments.

______________________

J'ai un doute pour ça :

J'ai alors créé un répertoire dans /home avec mon prénom effectif, et je l'ai renvoyé sur /home/arbiel.

…tu n'as probablement pas créé un répertoire mais plutôt un lien symbolique nommé ton_prénom qui a pour cible le dossier arbiel
→ là ça « matche » ça correspond car le $HOME de arbiel, ou un lien symbolique ciblant ce dossier, appartiennent à un seul utilisateur arbiel d'uid 1000, à l'attention de la seule session Arbiel.
→ chez Goliath60 on a 2 utilisateurs différents, vadee d'uid 1000 et enfants d'uid 1001. Un lien symbolique /home/enfants ciblant /home/vadee aurait donc présenté à la session enfants d'uid 1001 un $HOME ne lui appartenant pas, celui de vadee d'uid 1000, conduisant au même échec ( le $HOME d'une session doit forcément appartenir à l'utilisateur propriétaire de cette session, en avoir et le nom $USER et l'uid $UID ).

Les éléments indiquent leurs propriétaires via les uid et gid numériques. Dans un système donné, les noms correspondants à ces uid et gid sont consignés dans le fichier /etc/passwd

[ edit ] pour essayer de clarifier le propos.

Dernière modification par Coeur Noir (Le 14/10/2022, à 00:39)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#51 Le 13/10/2022, à 15:28

Re : mot de passe indépendant pour les enfants [RESOLU]

#52 Le 13/10/2022, à 15:33

Re : mot de passe indépendant pour les enfants [RESOLU]

#53 Le 13/10/2022, à 15:34

Re : mot de passe indépendant pour les enfants [RESOLU]

#54 Le 13/10/2022, à 15:39

Re : mot de passe indépendant pour les enfants [RESOLU]

#55 Le 13/10/2022, à 16:34

Re : mot de passe indépendant pour les enfants [RESOLU]

#56 Le 13/10/2022, à 16:55

Re : mot de passe indépendant pour les enfants [RESOLU]

#57 Le 13/10/2022, à 18:12

Re : mot de passe indépendant pour les enfants [RESOLU]

#58 Le 13/10/2022, à 19:39

Re : mot de passe indépendant pour les enfants [RESOLU]

#59 Le 13/10/2022, à 20:20

Re : mot de passe indépendant pour les enfants [RESOLU]

Pied de page des forums