Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

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

Coeur Noir

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/fix-broken-snapd-on-solus-linux/
⋅ https://discuss.getsol.us/d/1800-snap-software-are-not-working
⋅ https://devilzlinux.blogspot.com/2018/09/snap-run-spotify-cannot-change-profile.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 ?

Almtesh

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

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-the-owner-permission/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 ;-)

Almtesh

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

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.

« Page précédente