Snap refuse de lancer une application : libudev.so.1: Permission denie

Almtesh · Le 11/11/2020, à 14:01

Bonjour,

J'ai voulu installer une application avec snap. J'ai commencé à installer le paquet snapd.
J'ai ensuite installé une application avec la commande

sudo snap install spotify

, l'installation se déroule sans problème.
Maintenant, je veux le lancer (si quelqu'un sait comment mettre les raccourcis dans le menu d'applications, je prends), j'obtiens l'erreur suivante :

┌ (gilles@Thorn + 0) (11/11/20 - 12:54:38) (1.96 - 0%) (~)
└% snap run spotify
2020/11/11 12:54:45.412207 cmd_run.go:570: WARNING: XAUTHORITY environment value is not a clean path: "/mnt/data/home/gilles/.Xauthority"
/usr/lib/snapd/snap-confine: error while loading shared libraries: libudev.so.1: cannot open shared object file: Permission denied
┌ (gilles@Thorn + 127) (11/11/20 - 12:54:45) (1.82 - 0%) (~)
└%

Une idée ?

geole · Le 11/11/2020, à 16:34

Bonjour
Cela me semble normal. En standard, snap doit rester confiné dans /home, $HOME
Pour lui permettre de faire n'importe quoi, il faut une option spéciale au moment d'installer l'application
=> j'ai trouvé ce lien https://snapcraft.io/docs/snap-confinement

Dernière modification par geole (Le 11/11/2020, à 16:57)

Almtesh · Le 11/11/2020, à 16:40

Ah, super, mais est-il possible de configurer snap pour se confiner dans un autre répertoire ? En fait, j'aimerai bien que les snaps s'exécutent dans un espace dans lequel mon home n'est pas visible.
Attends, il se confine dans /home. Mais, ça veut dire que /home doit être un dossier, je suppose, non ?

geole · Le 11/11/2020, à 16:55

/home (en fait c'est $HOME) est un dossier! Le tien. Le but initial d'un snap est de travailler chez toi et pas chez les autres.
Si tu n'as pas confiance à un snap et c'est ton droit. Fabriques alors un utilisateur snap ou snapgilles et connecte-toi sous ce nom pour l'utiliser

Dernière modification par geole (Le 11/11/2020, à 17:34)

inbox · Le 11/11/2020, à 17:08

Salut,

J'ai trouvé ce sujet sur le launchpad. Cela renvoie vers les limitations connues pour l'utilisation de Snaps.

A+

[Edit] Peut-être un contournement ici ?

Dernière modification par inbox (Le 11/11/2020, à 17:10)

Almtesh · Le 11/11/2020, à 17:10

Alors, sur mon système, /home n'est pas un dossier et $HOME n'est pas /home.
Les snaps que je veux exécuter vont afficher une fenêtre graphique et je ne pense pas que les applications exécutées en tant que pas moi pourront ouvrir une fenêtre dans une session graphique en tant que moi.
Après, ce que je voulais, c'est que le snap travaille dans le dossier $HOME/.local/snap, par exemple. Ça me va très bien, mais il semblerait que modifier la valeur de la variable HOME ne change pas quoique ce soit.

Dernière modification par Almtesh (Le 11/11/2020, à 17:10)

grandtoubab · Le 11/11/2020, à 17:39

il faudrait au moins vérifier la présence de cette lib qui provoque l'erreur

locate libudev.so.1

entres autres

ls -alrt /usr/lib/x86_64-linux-gnu/libudev.so.1
lrwxrwxrwx 1 root root 17 15 oct.  23:48 /usr/lib/x86_64-linux-gnu/libudev.so.1 -> libudev.so.1.6.18

Almtesh · Le 11/11/2020, à 18:02

Tiens, tu es là aussi ?

┌ (gilles@Thorn + 0) (11/11/20 - 16:59:48) (0.77 - 0%) (~)
└% ls -l $(locate libudev.so.1)
lrwxrwxrwx 1 root root   17 oct.   8 22:14 /usr/lib/x86_64-linux-gnu/libudev.so.1 -> libudev.so.1.6.17
-rw-r--r-- 1 root root 175K oct.   8 22:14 /usr/lib/x86_64-linux-gnu/libudev.so.1.6.17

Les droits sont corrects.

Coeur Noir · Le 11/11/2020, à 18:13

Alors, sur mon système, /home n'est pas un dossier et $HOME n'est pas /home.
What is that charabia ?

Tu n'as pas de dossier /home dans ton système Linux ?
Et dans ce dossier /home il n'y a pas un dossier correspondant à chaque utilisateur « humain » du système ?
[ c'est possible, hein, mais alors ton système est peu commun ]

C'est vrai que l'erreur de langage est courante : /home c'est le dossier où le système range les répertoires perso des utilisateurs.
Ton répertoire perso ( appelé parfois le home de l'utilisateur, à tort je trouve ) c'est /home/$USER
Qu'importe que /home soit un dossier local dans la partition racine, ou un point de montage pour la partition d'un autre disque : ici on parle de la désignation logique ( pour le système ) pas physique.

Par contre, effectivement, snap pratique du confinement. Ça veut dire que snap limite autant que possible les interactions entre une appli snap et le système.
En général, de base un snap accède à
⋅ /home
En connectant tel snap à l'interface removable-media il peut alors aussi accéder à
⋅ /media
⋅ /mnt
⋅ /run/media
Et rien d'autre. Certains snap ont par défaut cette interface removable-media activée, d'autres non.

Pour savoir à quelles interfaces le snap de spotify est connecté

snap connections spotify

Pour lui ajouter le cas échéant la connection à removable-media

snap connect spotify:removable-media

Cela peut aussi se faire « en graphique » depuis
⋅ paramètres système / applications / spotify
⋅ logiciels / la page de spotify / bouton permission ou autorisations ( à côté de supprimer / installer en haut à gauche ).

Chez toi, ton répertoire perso semble dans :

/mnt/data/home/gilles/

normal donc que le snap n'y accède pas par défaut, l'ajout de removable-media devrait solutionner.

Globalement, et si tu n'utilises pas du tout le dossier /home de la racine système, ton Ubuntu est-il au courant que ton répertoire $USER n'est pas dans /home ?

Après, ce que je voulais, c'est que le snap travaille dans le dossier $HOME/.local/snap
Sauf que c'est pas comme ça que ça marche, un snap : chaque instance est montée comme un périphérique virtuelle ( /dev/loop× ).
C'est l'autre partie du confinement en quelque sorte, une exécution hors système.

si quelqu'un sait comment mettre les raccourcis dans le menu d'applications, je prends
Ça par contre ça m'étonne un peu, je crois que tous les snap mettent leur lanceur dans le menu d'app.
Peut-être lié au point précédent ( ajouter l'interface removable-media ) à voir si ça persiste.
Sinon au pire du pire, le lanceur de spotify en snap se trouve à prori dans /var/lib/snapd/desktop/applications tu peux le copier-coller dans ~/.local/share/applications

Almtesh · Le 11/11/2020, à 18:32

Merci pour ta réponse.

En fait, /home est un lien symbolique vers /mnt/data/home. Il est là parce que le dossier /mnt/data est en fait un point de montage en NFS.
Du coup, /home/gilles (ou $HOME) est bien un dossier qui existe et qui contient mon home. J'ai fait le montage ainsi car il correspond à un dossier /mnt/data sur le serveur NFS et qu'il contient d'autres dossiers qui doivent être présents aussi.

Mais, alors, ça veut dire que le répertoire des dossiers utilisateurs dans snap est défini en dur comme étant /home, c'est ça que tu es en train de me dire ?

J'ai globalement compris le concept, en fait, les snaps sont des fichiers en squashfs qui contiennent l'application et qui sont montés dans un sous-dossier du dossier /snap et de paramètres qui sont stockés dans $HOME/snap

Pour mettre les lanceurs à la main, j'avais déjà cette astuce, mais, ce que voulais, c'est savoir comment faire pour que ça se mettre automatiquement.

Coeur Noir · Le 11/11/2020, à 21:43

Mais, alors, ça veut dire que le répertoire des dossiers utilisateurs dans snap est défini en dur comme étant /home, c'est ça que tu es en train de me dire ?
Non.
Snap, comme n'importe quelle autre application, prendra ce que tu as mis dans /home. Si chez toi /home est un lien qui cible /mnt/data/home alors /home existe d'un point de vue logique ( logiciel, système ) mais d'un point de vue physique, les ressources sont sur une partition de disques différentes de / ( qui contient le dossier /home qui chez toi est un lien vers… ).
Comme physiquement la cible de ton lien est en dehors de /home, il faut d'abord donner au snap l'autorisation d'accéder à autre chose que /home ( puisqu'en fait c'est /mnt/… qui est visé ).
Et bien sûr gérer les droits et permissions en conséquence sur ces ressources - mais ça c'est pas spécifique à snap, c'est Linux.
Et snap ne fait que suivre les recommandations.

Je crois que ce que je suis en train de te dire c'est que tu confonds peut-être la désignation logique d'une arborescence de dossiers/fichiers avec l'emplacement physique des données associées à ces dossiers/fichiers.

le dossier /mnt/data est en fait un point de montage en NFS
Je ne suis pas spécialement coutumier du NFS mais assez coutumier de l'organisation de données en réseau, entreprise.
Dans ce /mnt/data il y a donc un dossier /home avec plein de dossiers $USER dedans. Ce gros /home centralise sur un réseau local toutes les datas des utilisateurs. C'est ça ?

T'as du jongler un peu pour réussir à remplacer le dossier /home par un lien, non ? Parce que selon le moment ou circonstances où t'essaies de faire ça ton système ne voit plus les dossiers $USER et ne sait plus lancer leur session graphique.

À la longue, j'en suis venu à faire le moins de modifications possibles sur la racine logique du système, ça facilite la maintenance de ne porter des modifications que sur quelques fichiers, mais toujours les mêmes, partout.
De plus les liens ( directs ou symboliques ) ça peut être très pratique mais éventuellement fragile ( ça s'efface facilement, un lien ).
Donc perso j'aurais pas touché au dossier /home et plutôt utilisé des montages --bind ( monter un dossier dans un autre ) à la fin de /etc/fstab

/mnt/data/home/utilisateur_1000	/home/utilisateur_1000	none	bind
/mnt/data/home/utilisateur_1001	/home/utilisateur_1001	none	bind
…
…
/mnt/data/home/utilisateur_1015	/home/utilisateur_1015	none	bind

Un inconvénient potentiel là ( ou au contraire un avantage, à voir selon ton contexte ) : dans le répertoire perso de chacun il y a bien sûr des datas ( Documents, Images, etc ) mais aussi, cachées, les config's perso des divers logiciels utilisés.
Ces config's seront plus efficaces ( rapidité d'accès ) si stockées localement dans la racine système.
Les montages --bind ne devraient concerner que leurs datas, genre :

/mnt/data/home/utilisateur_1009/Documents	/home/utilisateur_1009/Documents	none	bind
/mnt/data/home/utilisateur_1009/Images	/home/utilisateur_1009/Images	none	bind
/mnt/data/home/utilisateur_1009/Bureau	/home/utilisateur_1009/Bureau	none	bind
etc, etc

à faire pour chaque utilisateur.

Dans ce cas, les fichiers cachés de config's de chacun restent stockés ( physiquement ) dans chaque /home/$USER sur le disque système de l'ordi tandis que leurs autres datas proviennent de /mnt/data/home/$USER/… qui est en fait ta ressource NFS. L'utilité dépend du contexte : si tu préfères avoir toutes les affaires de l'$USER en un seul endroit. Ou si ça te dérange pas trop d'éventuellement copier d'un PC à l'autre les /home/$USER ( qui ne contiennent alors que des config's et pas des datas ).

Dernière modification par Coeur Noir (Le 11/11/2020, à 22:08)

Coeur Noir · Le 11/11/2020, à 22:14

Pour mettre les lanceurs à la main, j'avais déjà cette astuce, mais, ce que voulais, c'est savoir comment faire pour que ça se mettre automatiquement.
Les lanceurs snap sont normalement automatiquement intégrés à l'app-menu.
Règle d'abord le problème d'accès ( removable-media ).
Si ça ne résout pas, il faudra enquêter davantage, l'organisation de ton système n'étant pas « ordinaire ».

Almtesh · Le 11/11/2020, à 22:24

Je ne comprend pas ce que tu veux dire au sujet des droits sous Linux. J'ai mis les même droits d'accès que le dossier /home est censé avoir, à savoir :

drwxr-xr-x 6 root root 4,0K sept. 23 21:27 /mnt/data/home

Je ne sais pas quels droits il faut que j'ajoute. Est-ce que tu veux parler de mécanisme tels que apparmor ?

Concernant le montage en NFS, je ne suis pas dans un cas de réseau d'entreprise, c'est chez moi que j'ai ça. Je n'ai pas d'autres utilisateurs.
J'avais essayé le montage en bind, mais j'avais des problèmes, le système ne démarrait pas. De ce que j'en ai compris, le montage bind se faisait avant le montage NFS, bien que celui-ci soit placé après dans le fichier idoine.

Sinon, pour ta suggestion de faire plusieurs montages bind pour les dossiers présents dans mon répertoire et en exclure les configurations, ça ne changera rien, en plus de compliquer inutilement la configuration car le « disque système » est en NFS.

Coeur Noir · Le 12/11/2020, à 00:04

Euh… alors pourquoi as-tu besoin de NFS ?
Ou pourquoi ne pas monter ta ressource NFS directement dans /home ?
le « disque système » est en NFS
Euh… bis. Ça ↑ n'a aucun sens.

NFS est l'abréviation de Network File System, c'est-à-dire système de fichiers réseau.
Ce système de fichiers en réseau permet de partager des données principalement entre systèmes de type UNIX…
C'est pour ça que garder les config's perso sur le disque de l'ordi local est intéressant, plutôt que de les stocker plus loin, plus lentement, sur le réseau.
Car c'est à ça que sert NFS partager des fichiers à travers un réseau.
Si chez toi il n'y a qu'un seul ordi, NFS n'a aucune utilité.

lsblk -fe7 -o +size

pour voir l'orga de tes disques, partitions et points de montage.

ls -la /home

pour confirmer sa nature et droits.
Ça n'est pas seulement /home qui compte mais /home/$USER
Et

cat /etc/fstab

pour savoir quelles ressources sont montées dès le démarrage de ton pc.

J'avais essayé le montage en bind, mais j'avais des problèmes, le système ne démarrait pas
Avant ou après avoir remplacé le dossier /home par un lien vers /mnt/… ?
Sans mieux « voir » ton système, le fait d'avoir joué avec /home peut facilement expliquer pourquoi le démarrage a coincé.

Dernière modification par Coeur Noir (Le 12/11/2020, à 00:05)

Almtesh · Le 12/11/2020, à 09:12

Bonjour,

Voici les retours de commandes :

┌ (gilles@Thorn + 0) (12/11/20 - 8:08:05) (1.47 - 0%) (~)
└% sudo lsblk -fe7 -o +size
┌ (gilles@Thorn + 0) (12/11/20 - 8:08:07) (1.47 - 0%) (~)
└% ls -la /home
lrwxrwxrwx 1 root root 14 oct.  30 06:54 /home -> /mnt/data/home
┌ (gilles@Thorn + 0) (12/11/20 - 8:08:36) (1.29 - 0%) (~)
└% cat /etc/fstab
tmpfs                           /tmp            tmpfs   defaults
tmpfs                           /var/tmp        tmpfs   defaults

10.255.1.2:/mnt/data            /mnt/data       nfs     async,noatime,vers=3,hard,bg,local_lock=all

Quand j'ai testé le mount bind, j'avais bien pensé à supprimer le lien /home et le remplacer par un dossier avec aucun accès (je fais

mkdir -m 0000 <dossier>

pour tous mes points de montage, pour éviter que des données soient mises dessus en cas de problème de montage et qu'une erreur arrive vite si je ne le vois pas avant).

Coeur Noir · Le 12/11/2020, à 18:59

Euh… par défaut le dossier /home
⋅ appartient à root ( utilisateur + groupe )
⋅ droits rwxr-xr-x soit mode 0755 ou mask 0022
Si tu lui mets mode 0000 forcément rien ni personne ne verra/accédera/pourra utiliser ce dossier, ni lien, ni montage.

Dans /home chaque dossier $USER appartient à $USER ( utilisateur + groupe ) avec droits 755.

Voir → droits et permissions

/home
est actuellement chez toi un lien ( lrwxrwxrwx ) vers /mnt/data/home
Un lien ( ou un montage bind ) reporte les droits de sa source, il faut donc les consulter sur la cible :

ls -la /mnt/data/home

fstab
pas de racine / système ?

lsblk
zéro retour ? pas normal.

nfs
pas de réponse / réaction de ta part à
⋅ pourquoi as-tu besoin de NFS ?
⋅ Si chez toi il n'y a qu'un seul ordi, NFS n'a aucune utilité.

Je pense qu'il me manque des éléments pour comprendre le contexte de ton système ou de ton organisation, ce que tu veux « faire ».
Là avec ce que je vois, j'aurais tendance à penser que cette installation d'Ubuntu est complètement bancale.

Retour de

printenv

pourrait confirmer.

Dernière modification par Coeur Noir (Le 12/11/2020, à 19:07)

Almtesh · Le 12/11/2020, à 20:37

En fait, pour les points de montage, je mets 0000 pour empêcher à tout le monde d'y accéder. Les droits des points de montage est écrasé par les droits de la racine du système monté. Si ce n'était pas le cas, ça ferait longtemps que je m'en serais rendu compte.

Alors, pour le système racine, il n'est pas dans fstab car fstab est dans le système racine. Je pense que ce retour de commande pourra t'aider à comprendre un peu mieux.

┌ (gilles@Thorn + 0) (12/11/20 - 19:05:56) (1.19 - 0%) (~)
└% cat /proc/cmdline 
BOOT_IMAGE=tftp://10.255.1.2//srv/netboot/systems/thorn/boot/vmlinuz ip=dhcp nfsroot=10.255.1.2:/srv/netboot/systems/thorn root=/dev/nfs rw initrd=tftp://10.255.1.2//srv/netboot/systems/thorn/boot/initrd.img

Concernant le retour de lsblk, c'est tout à fait normal de ne rien voir car, d'après son manuel, il liste les prériphériques block. Les périphériques block sur Thorn ne sont pas légion, à part le lecteur optique, mais il n'y a pas de disque dedans.

Concernant le NFS, pardon, je n'ai pas vu les questions. J'ai besoin de NFS pour accéder aux différents stockages de mon réseau. Il est vrai que Thorn est, actuellement, le seul client NFS de mon réseau, mais ça n'a pas toujours été le cas et il n'est pas sûr que ça le reste. En fait, Thorn (et son prédécesseur Stardust) n'a jamais eu de disque dur, de SSD ou autre stockage. Cette configuration sans disque a survécu à différentes version de Debian, d'Ubuntu et quelques temps Arch. À un moment, ça a même été en iSCSI, mais c'était une galère sans nom, en plus d'être moins résiliant et plus compliqué.

Donc, puisque tu veux plus d'informations, je vais te donner quelques informations utiles sur mon infrastructure informatique.
Lookout est un Raspberry Pi sous Raspbian 10 qui me sert de routeur et de serveur DHCP. Il fournit les informations necessaires aux clients du réseau pour démarrer par le réseau et les renvoie vers le serveur TFTP du réseau.
Worm (10.255.1.2) est un, heu, ordinateur sous Debian 10 qui embarque un serveur TFTP et un serveur NFS (version 2, je n'ai que des problèmes avec la 3). Sur ces deux serveurs, j'ai un partage qui se trouve dans /srv/netboot/systems/thorn/ qui contient le système de fichiers racine de Thorn. J'ai aussi le serveur NFS qui sert le dossier /mnt/data.
Et j'ai Thorn, un, heu, ordinateur aussi sous Ubuntu 20.04 qui, au démarrage, récupère une configuration IP et de démarrage EFI de la part de Lookout pour aller chercher l'armorce, puis le noyau et l'image mémoire de démarrage de Worm par TFTP, pour la lancer et monter les systèmes de fichiers dans les options de démarrage et dans le fichier fstab.
Donc, non, pardon, mon installation d'Ubuntu n'a rien de bancale, elle tient tout à fait la route. Les seuls problèmes que j'ai eu, c'était la commande ping sous Debian 10 qui ne pouvait pas fonctionner à cause de problèmes de droits d'accès au réseau et ce problème snap et la commande man qui ne fonctionne pas non plus sous Ubuntu 20.04. Heu, d'ailleurs, quand j'y pense, elle me retourne un peu la même erreur :

┌ (gilles@Thorn + 0) (12/11/20 - 19:31:32) (1.07 - 0%) (~)
└% man snap
man: error while loading shared libraries: libmandb-2.9.1.so: cannot open shared object file: Permission denied
┌ (gilles@Thorn + 127) (12/11/20 - 19:32:34) (0.76 - 0%) (~)
└%

Faut-il y voir un lien, aucune idée.

Coeur Noir · Le 12/11/2020, à 21:20

Ok, oui je ne pouvais rien deviner de ton organisation !
Dans une telle organisation, comment chaque machine définit ses variables d'environnement, par exemple : XAUTHORITY ?
Chez toi ça sera /mnt/data/home/gilles/.Xauthority mais par défaut Ubuntu attend /home/$USER/.Xauthority d'où le

snap run spotify
2020/11/11 12:54:45.412207 cmd_run.go:570: WARNING: XAUTHORITY environment value is not a clean path: "/mnt/data/home/gilles/.Xauthority"

Il y a peut-être aussi une limite de snap : https://forum.snapcraft.io/search?q=nfs et ceux postés par Inbox au #5
Il faut que tu trouves le moyen que sur chaque machine la « ressource » /home/… soit disponible et accessible avant que snap n'en ait besoin pour y retrouver ses petits, en gros.

Et permission denied peut tenir parfois à pas grand' chose : est-ce que sur toutes les machines l'user machin a toujours le même uid ?

Serveurs DHCP, TFTP ça dépasse mes compétences mais si tu es sûr de ton coup de ce côté là, alors c'est probablement juste une question de config' / variables à définir côté Ubuntu sur l'ordi « client ».
Moderato la disponibilité préalable de /home pour snap.

Sinon, snap pour spotify t'es pas obligé, y'a du .deb : https://www.spotify.com/fr/download/linux/

curl -sS https://download.spotify.com/debian/pubkey_0D811D58.gpg | sudo apt-key add - 
echo "deb http://repository.spotify.com stable non-free" | sudo tee /etc/apt/sources.list.d/spotify.list

puis

sudo apt update && sudo apt install spotify-client

Dernière modification par Coeur Noir (Le 12/11/2020, à 21:50)

Almtesh · Le 12/11/2020, à 22:00

Bon, voilà, à un moment, il faut avancer, j'ai donc modifié ma configuration. J'ai éteint Thorn, j'ai ajouté cette ligne dans son fstab

10.255.1.2:/mnt/data/home       /home           nfs     async,noatime,vers=3,hard,bg,local_lock=all

J'ai supprimé le lien symbolique home pour le remplacer par un dossier vide, puis j'ai relancé Thorn et c'est reparti.

Tout fonctionne comme avant pour les applications normales, puisque, concrètement, rien n'a changé. Je peux toujours utiliser ping et man me retourne la même erreur.

Par contre, les lancements des snap donne une autre erreur :

┌ (gilles@Thorn + 0) (12/11/20 - 20:55:21) (0.93 - 0%) (~)
└% snap run spotify
cannot update snap namespace: cannot load desired mount profile of snap "spotify": open /var/lib/snapd/mount/snap.spotify.fstab: permission denied
snap-update-ns failed with code 1: File exists
┌ (gilles@Thorn + 1) (12/11/20 - 20:55:28) (0.95 - 0%) (~)
└% snap run hello-world
cannot update snap namespace: cannot load desired mount profile of snap "hello-world": open /var/lib/snapd/mount/snap.hello-world.fstab: permission denied
snap-update-ns failed with code 1: File exists
┌ (gilles@Thorn + 1) (12/11/20 - 20:55:34) (0.87 - 0%) (~)
└%

Je n'aime pas particulièrement cette configuration car mon home n'est plus dans /mnt/data du point de vue de Thorn et ça me fait monter deux fois le même export NFS, mais ça peut donner un point de vue différent sur la situation.
Ah, oui, et j'ai installé le snap hello-world, pour avoir un snap plus simple à lancer.

Coeur Noir · Le 12/11/2020, à 22:25

Quelles permissions sur ton dossier /home ? Je sais tu vas me dire que les permissions seront écrasées par celles du montage, mais quand même… snap est chafouin avec les permissions.
Et a besoin de « monter » des squashfs en /dev/loop× donc il faut que le système ( sur ton pc client ) en soit capable. Or sur un système sans disque que se passe-t-il ?

Si l'english t'embête pas, tu auras des pistes plus « précises » sur https://forum.snapcraft.io/ car ça a l'air de confirmer que ça ne concerne que snap ( c'est juste man snap, pas tous les man ? ).

Coeur Noir · Le 13/11/2020, à 00:24

Est-ce que ceci est vérifié
sur toutes les machines l'user machin a toujours le même uid ?
ou est-ce que c'est acquis / assuré par ton organisation serveur-client ?

Le nom en toutes lettres d'un $USER n'a quasi aucune importance, ce qui compte c'est son uid numérique.
Si dans le système qui tourne sur le pc client gilles a l'uid 1002 il faut impérativement que le dossier personnel cible ( et tout son contenu ) /mnt/data/home/gilles aient le même uid sinon → permission denied car propriétaire différent ( alors que le nom en toutes lettres pourra être identique ).

Relatifs à snap :
⋅ https://megamorf.gitlab.io/2020/04/04/f … lus-linux/
⋅ https://discuss.getsol.us/d/1800-snap-s … ot-working
⋅ https://devilzlinux.blogspot.com/2018/0 … ofile.html

Question bonus, pour ma curiosité : s'il n'y a pas de disque sur le pc client, le système y est complètement chargé en RAM, comme une session live ?

Dernière modification par Coeur Noir (Le 13/11/2020, à 01:13)

Almtesh · Le 13/11/2020, à 08:11

Alors, sur toutes mes machines, il y a un utilisateur gilles qui porte l'uid 1000 et qui a pour groupe primaire sudo qui a le gid 27. Donc, oui, l'uid est le bien le même partout.
C'est assuré par la configuration que je fais sur chaque machine perso que j'installe.

┌ (gilles@Thorn + 0) (13/11/20 - 6:55:42) (0.25 - 0%) (~)
└% ls -ldn ~
drwx------ 28 1000 27 4,0K nov.  13 06:32 /home/gilles
┌ (gilles@Thorn + 0) (13/11/20 - 6:55:44) (0.25 - 0%) (~)
└% ls -ld ~ 
drwx------ 28 gilles sudo 4,0K nov.  13 06:32 /home/gilles
┌ (gilles@Thorn + 0) (13/11/20 - 6:55:48) (0.23 - 0%) (~)
└% getent passwd $USER
gilles:x:1000:27:Gilles MOREL:/home/gilles:/bin/zsh
┌ (gilles@Thorn + 0) (13/11/20 - 6:56:19) (0.14 - 0%) (~)
└%

Sinon, pour ta question bonus, j'ai un ami qui a pratiqué le système chargé en RAM, mais je n'ai jamais essayé personnellement, je trouve que les installations de logiciel et les mises à jour sont trop complexes. Donc, non, ce n'est pas comme une session live, c'est plutôt comme un système installé, sauf qu'au lieu d'avoir un système de fichier en ext4 (ou autre) sur un périphérique bloc en lecture-écriture, le système de fichier est dans un export nfs.

Sinon, pour tes liens, les deux premiers sont pour Solus, et non Ubuntu et le troisième, je n'ai pas bien compris ce qu'il fallait faire, apparmor n'est pas en erreur chez moi.

Coeur Noir · Le 13/11/2020, à 18:10

Oui les liens c'était pour donner une idée générale → ça finit souvent par une réinstall' de snapd ou de configurer apparmor → https://forum.snapcraft.io/t/snaps-and- … on/21085/2
snap utilisant apparmor pour définir ce à quoi accède une appli', en cas de permission denied il n'y aura pas nécessairement d'erreur dans apparmor mais on peut se dire que apparmor devrait peut-être donner tel ou tel accès ?

Ton système sur nfs, exécuté par la machine cliente, n'est pas en lecture seule ? ( je suppose que non, sinon tu serais coincé ailleurs ).

Après tentative de lancer un snap

dmesg | grep audit:

devrait mettre en évidence des infos en rapport avec apparmor.

uid/gid d'un user. Sous Ubuntu, un utilisateur ( admin ou pas ) a par défaut un groupe de même id. S'il est admin' l'utilisateur fait aussi partie des groupes adm et sudo. Mais son groupe primaire n'est pas sudo. Exemple :

django@ASGARD:~$ id
uid=1000(django) gid=1000(django) groupes=1000(django),4(adm),20(dialout),21(fax),24(cdrom),25(floppy),26(tape),27(sudo),30(dip),44(video),46(plugdev),121(lpadmin),130(sambashare),134(lxd)

Là en gros je cherche à tâtons ce qui est différent chez toi d'une installation « basique » d'Ubuntu, qui expliquerait peut-être pourquoi tu trouves des permission denied dans certaines situations…
( soit : ça ne sert à rien d'attribuer sudo comme groupe primaire à un utilisateur, sous Ubuntu ).

D'ailleurs. Sur le système côté serveur nfs, à destination de la machine cliente, comment y as-tu créé l'utilisateur gilles ?

Mais ça se trouve, l'écueil tient simplement au fait que, comme le système depuis lequel tu lances snap est « derrière » un montage nfs, il ne parvient pas à accéder à /var/lib/snapd/mount/…
Et c'est probablement dans apparmor qu'il faudrait autoriser /mnt/le_système_distant/var/lib/snapd/… comme emplacement ??? S'il y a besoin de (re)configurer apparmor, c'est vraiment par là qu'il faudra demander conseil : https://forum.snapcraft.io/ car on touche là potentiellement au design de sécurité de snap ou une potentielle limitation de son confinement.

Sinon, rappel, snap n'a rien d'obligatoire pour spotify ;-)

Dernière modification par Coeur Noir (Le 13/11/2020, à 18:20)

Almtesh · Le 13/11/2020, à 19:01

Donc, petit retour sur les logs du noyau au lancement d'un snap :

[75640.566194] audit: type=1400 audit(1605285902.268:295): apparmor="DENIED" operation="capable" profile="/usr/lib/snapd/snap-confine" pid=80389 comm="snap-confine" capability=4  capname="fsetid"

Mon utilisateur gilles :

┌ (gilles@Thorn + 0) (13/11/20 - 17:46:45) (0.57 - 0%) (~)
└% id
uid=1000(gilles) gid=27(sudo) groups=27(sudo)
┌ (gilles@Thorn + 0) (13/11/20 - 17:46:52) (0.63 - 0%) (~)
└%

Je crée l'utilisateur gilles sur mes machines en lançant la commande suivante :

useradd --uid 1000 --gid sudo --comment "Gilles MOREL" --create-home --home /home/gilles --shell /bin/bash gilles
passwd gilles

Selon la machine, je mets --no-create-home si le home est censé déjà exister. Je mets mon mot de passe, puis je me connecte et je lance :

git clone https://code.almtesh.net/Almtesh/zsh.git .zsh
~/.zsh/install.sh

et mon utilisateur est prêt. Du coup, non, mon groupe primaire n'est pas un groupe inutile qui porte le même nom et le même id que l'utilisateur. Je trouve ça idiot de créer un groupe d'un utilisateur qui n'a que pour but d'être un groupe qui contient utilisateur.
Par contre, il y a un truc que je ne m'explique pas sur Thorn, gilles n'est ni dans video, ni dans audio, pourtant que je peux utiliser le son et la caméra sans problème.

Pour le NFS, non, le système racine est monté à la racine.

┌ (gilles@Thorn + 0) (13/11/20 - 17:56:08) (0.82 - 0%) (~)
└% ls -ld /var/lib/snapd/mount
drwxr-xr-x 2 root root 4,0K nov.  11 12:54 /var/lib/snapd/mount
┌ (gilles@Thorn + 0) (13/11/20 - 17:56:23) (0.64 - 0%) (~)
└%

Sinon, c'est la deuxième fois que tu me dis que snap n'est pas obligatoire pour spotify, j'ai pris note et je l'ai même installé, mais ce n'est pas que pour spotify que je veux mettre en œuvre snap. Je compte aussi installer chromium, electronplayer, powershell et probablement d'autres.

Coeur Noir · Le 13/11/2020, à 20:14

Pour le NFS, non, le système racine est monté à la racine
→ ok, mais il n'est pas « sur la machine » qui exécute le snap, c'est un montage. Le confinement snap réglé via apparmor attend probablement que ses petits soient tous « au même endroit ». C'est vraiment par là qu'il faut que tu cherches, et les faiseurs de snap t'aideront bien mieux que moi à ce sujet : https://forum.snapcraft.io/

mon groupe primaire n'est pas un groupe inutile qui porte le même nom et le même id que l'utilisateur
Quand il s'agit de partager des datas dans un contexte multi-utilisateurs, entre certains utilisateurs ou certains groupes d'utilisateurs, c'est terriblement pratique et utile.
Si ce comportement par défaut ne te convient pas, les options liées à la création d'utilisateur se règlent dans /etc/login.defs
En créant un utilisateur « admin » qui fait par conséquent déjà partie du groupe sudo, je ne vois pas l'intérêt de « sur-signifier » cette propriété. Un groupe plus neutre comme 100 ( = tous les utilisateurs ) me semble plus opportun.
C'est du pinaillage hors sujet je te l'accorde.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 11/11/2020, à 14:01

Snap refuse de lancer une application : libudev.so.1: Permission denie

#2 Le 11/11/2020, à 16:34

Re : Snap refuse de lancer une application : libudev.so.1: Permission denie

#3 Le 11/11/2020, à 16:40

Re : Snap refuse de lancer une application : libudev.so.1: Permission denie

#4 Le 11/11/2020, à 16:55

Re : Snap refuse de lancer une application : libudev.so.1: Permission denie

#5 Le 11/11/2020, à 17:08

Re : Snap refuse de lancer une application : libudev.so.1: Permission denie

#6 Le 11/11/2020, à 17:10

Re : Snap refuse de lancer une application : libudev.so.1: Permission denie

#7 Le 11/11/2020, à 17:39

Re : Snap refuse de lancer une application : libudev.so.1: Permission denie

#8 Le 11/11/2020, à 18:02

Re : Snap refuse de lancer une application : libudev.so.1: Permission denie

#9 Le 11/11/2020, à 18:13

Re : Snap refuse de lancer une application : libudev.so.1: Permission denie

#10 Le 11/11/2020, à 18:32

Re : Snap refuse de lancer une application : libudev.so.1: Permission denie

#11 Le 11/11/2020, à 21:43

Re : Snap refuse de lancer une application : libudev.so.1: Permission denie

#12 Le 11/11/2020, à 22:14

Re : Snap refuse de lancer une application : libudev.so.1: Permission denie

#13 Le 11/11/2020, à 22:24

Re : Snap refuse de lancer une application : libudev.so.1: Permission denie

#14 Le 12/11/2020, à 00:04

Re : Snap refuse de lancer une application : libudev.so.1: Permission denie

#15 Le 12/11/2020, à 09:12

Re : Snap refuse de lancer une application : libudev.so.1: Permission denie

#16 Le 12/11/2020, à 18:59

Re : Snap refuse de lancer une application : libudev.so.1: Permission denie

#17 Le 12/11/2020, à 20:37

Re : Snap refuse de lancer une application : libudev.so.1: Permission denie

#18 Le 12/11/2020, à 21:20

Re : Snap refuse de lancer une application : libudev.so.1: Permission denie

#19 Le 12/11/2020, à 22:00

Re : Snap refuse de lancer une application : libudev.so.1: Permission denie

#20 Le 12/11/2020, à 22:25

Re : Snap refuse de lancer une application : libudev.so.1: Permission denie

#21 Le 13/11/2020, à 00:24

Re : Snap refuse de lancer une application : libudev.so.1: Permission denie

#22 Le 13/11/2020, à 08:11

Re : Snap refuse de lancer une application : libudev.so.1: Permission denie

#23 Le 13/11/2020, à 18:10

Re : Snap refuse de lancer une application : libudev.so.1: Permission denie

#24 Le 13/11/2020, à 19:01

Re : Snap refuse de lancer une application : libudev.so.1: Permission denie

#25 Le 13/11/2020, à 20:14

Re : Snap refuse de lancer une application : libudev.so.1: Permission denie

Pied de page des forums