- Mail original -
De: "didier gaumet"
À: "Liste Debian"
Envoyé: Vendredi 24 Mars 2023 10:51:42
Objet: Re: Fwd: 'gio: Setting attribute metadata::trusted not supported'
Le 24/03/2023 à 00:11, roger.tar...@free.fr a écrit :
> Excusez-moi mais avez-vous déjà utilisé 'gio set' ??
>
> Comment assurez-vous la sécurité du système debian quand on utilise un
> GUI (gnome, et autre xfce4) pour faire tourner un script requérant les
> droits d'un sudoer ?
>
>
> *De: *"roger tarani"
> *À: *"Liste Debian"
> *Envoyé: *Mardi 14 Mars 2023 11:47:31
> *Objet: *'gio: Setting attribute metadata::trusted not supported'
>
> Bonjour,
>
> Je fais suite au fil de discussion *debian 11 - créer une "desktop
> icon"... simplement*.
> J'avais pu, avec un script bash exécuté par un sudoer, créer un lanceur
> sur le bureau avec une icône, lui donner les droits 700 (pour le sudoer
> qui exécute ce script). Impeccable.
>
> A cette occasion, j'ai aussi découvert les réglages de sécurité
> supplémentaires que j'ignorais (GUI...).
> Je suis allé jusqu'à les modifier avec cette commande exécutée en tant
> que sudoer ('sudo monscript.sh'). A son tour, root ($USER, tandis que le
> sudoer est représenté par $SUDO_USER) exécuteune commande sudo :
>
>
> sudo -u"${SUDO_USER}"bash-c'echo "${LAUNCHER}"; gio set "${LAUNCHER}"
> metadata::trusted true'&> /dev/null
>
>
> Ça semble faire exactement ce que ferait l'utilisateur avec un clic
> droit sur l'icône du lanceur "Allow launching" (ou dans le navigateur de
> fichiers ; clic droit Properties > Permissions > "Allow executing file
> as program").
>
> Le résultat obtenu est *opérationnel*, sauf cachotterie du système...
> Mais le script exécuté par l'utilisateur en tant que sudoer affiche un
> message d'erreur contradictoire ou lui-même erroné (ce qui serait un
> comble pour un message d'erreur !) :
>
> gio: Setting attribute metadata::trusted not supported
>
> D'où le &> /dev/null pour masquer ce message.
>
> Je veux m'assurer que ce qui marche aujourd'hui marchera, durablement,
> sur le système visé de l'utilisateur (debian 11, également).
>
> Comment expliquer que le changement est fait alors qu'un message suggère
> que cela n'est pas supporté ? (d'ailleurs : quoi, par quoi, pourquoi ?)
> Comment diagnostiquer ça ?
>
> Y a-t-il un rapport à explorer avec pkexec ou lxqt-sudo (et les anciens
> gksu/gksudo, obsolètes) à explorer ? (dont je ne connais quasiment rien
> à part les noms, puisque je n'ai jamais eu besoin de GUI...)
>
> Autrement dit, comment assure-t-on la sécurité du système debian quand
> on utilise un GUI (gnome, et autre xfce4) pour faire tourner un script
> requérant les droits d'un sudoer ?
>
> Merci.
>
Bonjour,
Avertissement habituel: je n'utilise pas gio (la commande, j'utilise
inconsciemment GIO/GVFS) donc ce que je dis est hautement sujet à
vérification et contradiction,
mais en gros et de loin je me demande si ton message d'erreur n'est pas
causé par le fait que la commande gio set est exécutée par root ce qui
pourrait poser problème (ressources GUI, utilisateur, et d'un point de
vue sécuritaire on considérerait que root n'a pas à s'en mêler). Donc
peut-être que la commande gio set gagnerait à être exécutées sans
élévation de privilèges?
(pure hypothèse peut-être fantaisiste et sans élément pour l'étayer
solidement)
RT: le programme est exécuté par un sudoer :
sudo mon_prog.sh
et root exécute cette commande en tant que $SUDO_USER :
sudo -u "${SUDO_USER}" bash -c 'echo "${LAUNCHER}"; gio set "${LAUNCHER}"
metadata::trusted true' &> /dev/null
Sinon (sans 'sudo -u "${SUDO_USER}" etc.') c'est root qui exécute la commande,
et alors ça ne fonctionne pas du tout.
Je ne sais pas dire si "le système" fait la différence entre :
- l'utilisateur lambda qui exécute un programme en tant que sudoer, lequel
programme exécute alors une commande 'gio set' concernant CE MÊME utilisateur.
- l'utilisateur lambda qui exécute une commande 'gio set'
D'un côté, j'aurais envie de dire oui, si on considère que "le système" peut
savoir que c'est bien l'utilisateur lambda, sudoer autorisé comme root, qui
confie à root le soin d'exécuter une commande pour l'utilisateur lambda.
$SUDO_USER permet au système de savoir que c'est lambda.
D'un autre côté, j'aurais envie de dire non, puisque dès lors que l'utilisateur
agit comme sudoer, alors il agit en tant que root et n'est plus cet utilisateur
lambda.
Mais pour répondre formellement, il faudrait connaître exactement le modèle de
sécurité implémenté par linux debian.
Pour chercher ça, pouvez-vous expliquer où le module qui fait ça est logé ?
