[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Fwd: 'gio: Setting attribute metadata::trusted not supported'



Le 24/03/2023 à 00:11, roger.tarani@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" <roger.tarani@free.fr>
*À: *"Liste Debian" <debian-user-french@lists.debian.org>
*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)


Reply to: