Forum Linux.général Connaître l'utilisateur et le groupe qui seront automatiquement propriétaires de nouveaux fichiers

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
3
7
nov.
2015

Bonjour,

J'aimerais savoir s'il existe une commande pour connaître l'utilisateur et le groupe qui seront automatiquement propriétaires de nouveaux fichiers ?

J'ai vu cette question dans un ancien examen de Linux de l'école où je suis étudiant, mais je n'ai pas encore trouvé de réponse.

Je sais qu'avec chmod g+s repertoire, on peut faire que tous les nouveaux fichiers créés dans repertoire appartiennent automatiquement au groupe propriétaire. J'ai même essayé un chmod u+s repertoire pour voir si je pouvais fixer l'utilisateur propriétaire, mais sans succès.

Ou peut-être que je comprends mal le sens de la question ?

En tout cas, je remercie d'avance tous ceux qui pourront me donner un coup de main.

  • # Umask

    Posté par  . Évalué à 1.

    Si je ne me trompe pas, le propriétaire du fichier sera celui qui l'aura créé.

    Sinon, pour les permissions qui seront attribuées au nouveau fichier, il y a umask.

    • [^] # Re: Umask

      Posté par  . Évalué à 1.

      Après avoir relu la question, je viens de m'apercevoir que ma réponse est peut-être un peu à côté de la plaque. mais bon il est tard…

      • [^] # Re: Umask

        Posté par  . Évalué à 1.

        Merci tout de même !

    • [^] # Re: Umask

      Posté par  (site web personnel) . Évalué à 3. Dernière modification le 07 novembre 2015 à 23:02.

      Réponse courte : non
      Réponse longue : ACL

      Quand à la question d'origine, le créateur du fichier est propriétaire, le groupe du créateur est propriétaire sauf si setgid sur le répertoire dans ce cas c'est le groupe défini sur le répertoire parent qui sera propriétaire.

      Regarde du côté de la commande stat

      Is it a Bird? Is it a Plane?? No, it's Super Poil !!!

      • [^] # Re: Umask

        Posté par  . Évalué à 1.

        Merci pour la commande stat ; elle donne des informations intéressantes, mais sur un fichier/répertoire déjà existant. Or, il s'agit de trouver une commande qui permette de "prédire" le propriétaire (user et group) d'un nouveau fichier. Je vais essayer de regarder du côté des ACL.

        Merci !

        • [^] # Re: Umask

          Posté par  (site web personnel) . Évalué à 0.

          La commande qui "prédit" l'utilisateur qui va exécuter une commande est su (swap user). Tu peux très bien l'utiliser avec touch, cp, vim …

          « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

      • [^] # Re: Umask

        Posté par  . Évalué à 4. Dernière modification le 08 novembre 2015 à 12:09.

        Quand à la question d'origine, le créateur du fichier est propriétaire, le groupe du créateur est propriétaire

        Du coup la commande pour prédire ce qui va en être depuis le script/shell courant c'est id, non?

        C'est vrai que c'est un peu tordu comme formulation du problème…

        • [^] # Re: Umask

          Posté par  . Évalué à 1.

          La commande id me convient, vu que l'utilisateur courant et son groupe sont censés être les propriétaires de tout nouveau fichier/dossier (sauf si le SGID est positionné sur le parent). Merci.

      • [^] # Re: Umask

        Posté par  (site web personnel) . Évalué à 2.

        Quand à la question d'origine, le créateur du fichier est propriétaire, le groupe du créateur est propriétaire sauf si setgid sur le répertoire dans ce cas c'est le groupe défini sur le répertoire parent qui sera propriétaire.

        C'est pas toujours vrai… On trouve des cas lors de copie ou le groupe reste le groupe d'origine.

        • [^] # Re: Umask

          Posté par  (site web personnel) . Évalué à 1.

          Il dit nouveau fichier.

          Is it a Bird? Is it a Plane?? No, it's Super Poil !!!

        • [^] # Re: Umask

          Posté par  (site web personnel) . Évalué à 1.

          Ceci n'est valable que pour le super utilisateur, une copie en utilisateur normal est soumise au réglé standard de création de fichiers

          • [^] # Re: Umask

            Posté par  (site web personnel) . Évalué à 2.

            J'ai des partages SMB et NFS ou les dossiers ont tous les sgid bit positionnés et ou je trouve régulièrement des fichiers ayant le mauvais groupe… Aucun utilisateur n'est root.

  • # commandes who, grep, cut, ...

    Posté par  (site web personnel) . Évalué à 1.

    Bonjour,

    Pour le propriétaire c'est facile. C'est l'utilisateur qui créée le fichier qui en est propriétaire. Pourquoi voudrais-tu créer des fichiers qui appartiennent à quelqu'un d'autre? Ton nom d'utilisateur peut être retrouvé avec la commande who am i ou who -m.

    Pour le groupe, si le bit s n'est pas positionné sur le répertoire, c'est le groupe par défaut de l'utilisateur qui est utilisé. Le numéro de ce groupe se trouve dans le fichier /etc/passwd. Pour connaitre le nom du groupe associé à un numéro, il faut regarder dans le fichier /etc/group.

    Je ne connais pas de commande donnant directement cette information. La bonne réponse à l'examen consiste peut-être à créer sa propre commande à l'aide de grep, de cut, et de pipes.

    • [^] # Re: commandes who, grep, cut, ...

      Posté par  (site web personnel) . Évalué à 2. Dernière modification le 07 novembre 2015 à 23:31.

      Getent passwd et cie…

      Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités

      • [^] # Re: commandes who, grep, cut, ...

        Posté par  . Évalué à 1.

        Ce qui est bizarre dans cette question, c'est qu'on demande une commande qui permet de dire à l'avance à qui appartiendra (user et group) un nouveau fichier, et non à qui appartient un fichier déjà créé. Sinon, merci pour l'aide !

        • [^] # Re: commandes who, grep, cut, ...

          Posté par  (site web personnel) . Évalué à 3. Dernière modification le 08 novembre 2015 à 20:09.

          Bah euh moi en 3 minutes je ferai :

          #!/bin/bash
[[ $# -ne 1 ]] && echo "Please give a folder" && exit 1

FOLDER=$1
[[ ! -d ${FOLDER} ]] && echo "${FOLDER} is not a folder" && exit 1

PERM=$(stat -c %a ${FOLDER})
if [[ ${#PERM} -eq 4 ]] && [[ ${PERM:0:1} -eq 2 ]]; then
  echo "New file in ${FOLDER} will have owner : $(id -un), group $(stat -c %G ${FOLDER})"
else
  echo "New file in ${FOLDER} will have owner : $(id -un), group $(id -gn)"
fi

          (copyright moi, il y a d'autre méthode je te laisse ne pas copier coller le script bêtement)

          Is it a Bird? Is it a Plane?? No, it's Super Poil !!!

          • [^] # Re: commandes who, grep, cut, ...

            Posté par  . Évalué à 1. Dernière modification le 08 novembre 2015 à 22:45.

            Wow ! Vraiment intéressant le script ! Je vois qu'il traite le cas où on a le SGID positionné sur le répertoire parent, ou non. Complet. Bravo ! J'achète volontiers !

            Mais je crois que id devrait être une réponse satisfaisante, puisqu'elle (la commande) donne l'utilisateur courant et son groupe, qui sont normalement censés être les propriétaires de tout nouveau fichier/répertoire (sauf bien sûr s'il y a le SGID sur le répertoire parent).

            • [^] # Re: commandes who, grep, cut, ...

              Posté par  . Évalué à 2.

              Wow ! Vraiment intéressant le script ! Je vois qu'il traite le cas où on a le SGID positionné sur le répertoire parent, ou non. Complet.

              En fait, non. La seule vraie réponse absolue à la question est décevante « ça dépend de la commande ».

              Un démon, par exemple, se lance habituellement en root puis change pour un utilisateur système (comme ça il y a moins de chances de ruiner le système en cas de compromission, mauvaise configuration ou bug). Donc rien n'empêche qu'il crée certains fichiers en root et d'autres en utilisateur, seule la documentation de la commande peut te le dire.

              De même, en partant d'un utilisateur non-privilégié, la commande peut être un script qui utilise sudo à certains endroits sans demander de mot de passe.

              C'est pour ça que je trouve la question ambiguë. Il aurait été plus clair de demander l'utilisateur et le groupe pour le fichier créé dans /tmp par une redirection du shell courant, par exemple.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.