Nouveautés dans Jammy

geole · Le 18/11/2021, à 15:26

Bonjour
Cela y est, je suis dans les ennuis. Il va falloir que je comprenne le confinement.
Le gparted c'est planté, J'ai sauvé le fichier HTML sur le bureau.
Auparavant, c'était un fichier consultable avec firefox. Mais maintenant le firefox est en SNAP et il y a refus de lecture. Je ne m'attendais à ce que le bureau ne soit pas consultable. Ou puis-je déposer le fichier pour avoir une meilleure lecture que par gedit?
Merci.

Malizor · Le 18/11/2021, à 15:30

@geole: Firefox snap peut parfaitement lire les fichiers sur ton Bureau, je viens de tester à l'instant.
En l'occurrence je pense que tu as un vrai problème de droit. Si ton fichier a été créé par gparted j'imagine qu'il doit appartenir à root. Un petit chown ou chmod sur le fichier devrait suffire je pense.

geole · Le 18/11/2021, à 15:35

Merci
En standard, il est root avec droit de lecture pour tout le monde. je l'ai mis en écriture pour tout le monde.
Cela n'a rien changé, Je vais m'en rendre propriétaire car c'est certainement le problème.

Coeur Noir · Le 18/11/2021, à 16:02

En standard, il est root avec droit de lecture pour tout le monde
il ? Qui ? Le dossier Bureau ? Ah non, le fichier html créé par gparted. Comme gparted est lancé par root, le fichier créé appartient à root - et firefox en snap n'ouvrira que des fichiers appartenant au même utilisateur que celui qui lance firefox-snap à ce moment là.
Je vais m'en rendre propriétaire car c'est certainement le problème. → c'est bien ce qu'il faut faire et ça n'est pas un problème.
Ici le « problème » c'est plutôt que gparted écrit chez toi dans /home/toi/Bureau un fichier qui n'appartient pas à toi.

Quelques « bases » du confinement dans snap :
⋅ seuls certains emplacements sont accessibles aux snap → /home et /media, /run/media, /mnt lorsque le snap en question est connecté à l'interface removable-media,
⋅ snap utilise strictement les droits et permissions → un snap lancé par l'utilisateur machin accédera aux fichiers de l'utilisateur machin s'il est l'utilisateur propriétaire, ou s'il est membre du groupe propriétaire dudit fichier,
⋅ et autres subtilités impliquant apparmor et l'exécution des processus dans des montages de périphériques virtuels hors système en cours ( les /dev/loop/… )

geole · Le 18/11/2021, à 16:21

Coeur Noir a écrit :

Quelques « bases » du confinement dans snap :
⋅ snap utilise strictement les droits et permissions → un snap lancé par l'utilisateur machin accédera aux fichiers de l'utilisateur machin s'il est l'utilisateur propriétaire, ou s'il est membre du groupe propriétaire dudit fichier,

En clair si d'autres utilisateurs ont mis chez machin un fichier accessible en lecture/écriture chez machin par le monde entier. Le snap n'y accède pas.

Le piège est que machin lance gparted et que gparted en standard veut écrire dans /root, le dérouter chez machin n'est pas suffisant, il faut que machin s'en rendre propriétaire. Dans le temps ce n'était pas obligatoire.

J'ai fait cette commande

a@b:~/Bureau$ sudo chown root:a g*
a@b:~/Bureau$ ls -ls
total 12
12 -rwxrwxrwx 1 root a 9293 nov.  18 15:05 gparted_details.htm

toujours refusé
donc au final

a@b:~/Bureau$ sudo chown a:a g*
a@b:~/Bureau$ ls -ls
total 12
12 -rwxrwxrwx  1 a a 9293 nov.  18 15:05 gparted_details.htm
a@b:~/Bureau$

et c'est accepté.
La règle serait plutôt accès aux fichiers du répertoire $HOME dont $USER est propriétaire

Dernière modification par geole (Le 18/11/2021, à 16:38)

Malizor · Le 18/11/2021, à 16:53

Il y a en effet une restriction particulière au home alors, parce que par exemple

firefox /usr/share/doc/gdisk/index.html

marche très bien, alors que le fichier en question appartient à root:root.

Coeur Noir · Le 18/11/2021, à 17:56

geole a écrit :

En clair si d'autres utilisateurs ont mis chez machin un fichier accessible en lecture/écriture chez machin par le monde entier. Le snap n'y accède pas

Et ouais. On veut de la sécurité ou du confort ? Ça fait partie des mécanismes de confinement.
De plus ton fichier là a des droits d'exécution inutiles :

12 -rwxrwxrwx 1 root a 9293 nov.  18 15:05 gparted_details.htm

Essaie sans le x car rappel, les fichiers n'ont pas besoin d'être exécutables - sauf exceptions particulières du type lanceurs, binaires, librairies, bref des fichiers de nature exécutable.

Et on est bien d'accord que

a@b:~/Bureau$

se trouve sur une partition dont le système de fichiers gère nativement les droits et permissions Linux ?
Je sais que tu aimes bien NTFS et assez peu les questions de droits et permissions ;-)

À la base chez machin, on met les affaires de machin et pas celles d'autres utilisateurs.

Si truc doit ajouter des affaires chez machin et vice-versa, alors on ajoute
⋅ truc au groupe de machin,
⋅ machin au groupe de truc,
⋅ le droit d'écriture au groupe machin ( dont truc est dorénavant membre ) sur l'emplacement~dossier nécessaire chez machin, emplacement qui devient alors partagé en écriture entre machin et truc,
⋅ éventuellement le droit d'écriture au groupe truc ( dont machin est dorénavant membre ) sur l'emplacement~dossier nécessaire chez truc, emplacement qui devient alors partagé en écriture entre truc et machin
→ les dossiers dont le groupe n'a pas le droit d'écriture sont accessibles en lecture par truc et machin ( puisque truc et machin sont membre du groupe de l'autre ),
→ les éléments crées par l'un chez l'autre seront accessibles en lecture et effacement mais pas modifiables, car par défaut les fichiers d'un utilisateur sont réglés en rw-r--r-- (*)

[ edit ] pourquoi ce laïus sur droits et permissions ? Parce que les snap ne font « que » suivre les fondamentaux à ce sujet. Dans un contexte multi utilisateurs un snap lancé par machin pourra accéder et utiliser des fichiers de truc, si machin fait partie du groupe truc.

La règle serait plutôt accès aux fichiers du répertoire $HOME dont $USER est propriétaire

Je dirais plutôt : comme c'est un fichier exécutable appartenant à l’utilisateur root, snap ne le lance pas. Ce qui paraît logique d'un point de vue sécurité.

Là c'est plutôt le comportement de gparted qui serait à améliorer. Qu'il attribue à l'utilisateur de la session courante les fichiers créés, plutôt qu'à root qui a lancé gparted ( même si en soi c'est un comportement logique ).
C'est peut-être configurable via apparmor, pkexec ou polkit mais c'est au delà de mes connaissances concrètes.
Y'a le même genre de blague avec des rapports boot-info.

__________________________________________

(*) c'est l'UMASK global défini dans le fichier /etc/login.defs à 022 voire 027 depuis la 21.04 il me semble. À passer à 007 s'il s'agit de créer des fichiers modifiables par les utilisateurs membres d'un groupe.
Hélas un certain nombre d'appli's gnome ont du mal à suivre cet UMASK - un vieux bug signalé depuis des années, qui est peut-être résolu ?

Pour faciliter le partage en écriture complète entre utilisateurs membres d'un groupe, il y a sinon le bit sgid à placer sur le dossier partagé :
il donnera automatiquement aux fichiers crées dans ce dossier, le même groupe avec les mêmes droits que le groupe du dossier parent.
Illustration : dans le dossier partagé chez machin ( qui a le droit écriture, sur le groupe machin ), les éléments créés dedans par truc auront truc:machin comme propriétaires, avec droits rw au groupe.
Hop, machin peut modifier ce qui appartient à l'utilisateur truc, puisque ça appartient aussi dorénavant à machin via son groupe.

L'une ou l'autre ou les 2 façons cumulées ne sont pas « rétro-actives » : les droits des éléments existants avant ces réglages seront à harmoniser.

Dernière modification par Coeur Noir (Le 20/11/2021, à 14:23)

lynn · Le 19/11/2021, à 18:48

Pour l'instant, impossible d'installer... l'installateur plante !

FrancisFDZ · Le 20/11/2021, à 09:25

Ça me conforte dans ma décision : pas de snap chez moi, même en 22.04 !

Dernière modification par FrancisFDZ (Le 20/11/2021, à 09:26)

Poun64 · Le 22/11/2021, à 04:29

Bonsoir toul'monde !

lynn a écrit :

Pour l'instant, impossible d'installer... l'installateur plante !

Bin j'ai fait le même constat :
J'ai testé avec les deux versions (Ubuntu et Xubuntu 22.04) il y a quelques jours.
Je les ai téléchargées ici et ici.
Les deux ISO étaient OK, et les deux LiveUSB fonctionnaient bien, pourtant l'installation sur une clé USB de test plantait systématiquement...
Du coup, j'ai tout abandonné... Pour l'instant...

Dernière modification par Poun64 (Le 22/11/2021, à 04:30)

geole · Le 22/11/2021, à 10:49

Bonjour poun64
installation EFI? ou installation LEGACY?
Quel était le message d'erreur ?
Avais-tu pris l'option , "installation sur tout le disque" ? Si pas le cas, retente avec cette option puis en sélectionnant la clé USB, Elle doit être facile à reconnaître dans la liste proposée.

Poun64 · Le 22/11/2021, à 18:23

Bonsoir Geole, bonsoir toul'monde !

J'ai fait ce test sur mon PC principal de travail en mode Legacy.
Juste pour info, ce PC est compatible EFI mais comme le Windows 7 Legacy d'origine a été migré en Windows 10 (donc en Legacy également), je fais toutes mes installations sur un deuxième disque Xubuntu en Legacy pour que Grub voit mon Windows 10 et puisse démarrer dessus.

Je crois me souvenir que j'ai fait le test le la "22.04" avec une USB3 de 64Go - Table de partition msdos et deux partitions EXT4 (pour root et home), comme je faisais toujours et comme j'ai fait dernièrement pour tester une "21.10"... Je n'ai pas noté le message d'erreur qui était très générique, il était du genre "Erreur Ubiquity - L'installation a échoué...
J'essayerai à nouveau comme tu me suggères (disque entier) mais sans créer de partition EFI pour installer en Legacy aussi.

lynn · Le 22/11/2021, à 19:09

Le bug est signalé sur Launchpad : https://bugs.launchpad.net/ubuntu/+sour … ug/1951399

Il y a une méthode en #26 pour contourner ce bug.

Poun64 · Le 22/11/2021, à 19:41

Super info Lynn !
Je vais attendre un peu pour appliquer l'astuce si le bug n'est pas corrigé...
Pour l'instant, je me bats avec Grub pour qu'il veuille bien me lancer un Android-x86 installé sur une clé USB3...

lynn · Le 24/11/2021, à 16:27

C'est fonctionnel à nouveau avec l'ISO de ce jour 24/11/2021 8:31

https://cdimage.ubuntu.com/daily-live/current/

ft · Le 30/11/2021, à 19:20

Dites-moi, j'ai un bug pas bien grave mais bien connu et bien pénible : seahorse me demande fréquemment au démarrage de dévérouiller mon trousseau, alors que j'ai choisi (et rererechoisi) un mdp vide (= déverouillage sans mdp).
Si vous avez des infos, je prends.

FrancisFDZ · Le 01/12/2021, à 09:43

ft a écrit :

Dites-moi, j'ai un bug pas bien grave mais bien connu et bien pénible : seahorse me demande fréquemment au démarrage de dévérouiller mon trousseau, alors que j'ai choisi (et rererechoisi) un mdp vide (= déverouillage sans mdp).
Si vous avez des infos, je prends.

Il y a lieu de distinguer

le mdp root
le mdp $USER
le mdp éventuellement affecté à seahorse

Quand tu parles de "déverrouillage sans mdp", je suppose qu'il s'agit du mdp $USER demandé par défaut au démarrage (et peu utile sur un système monoutilisateur). Il y a bien une option dans le gestionnaire de connexion qui permet de s'en dispenser, mais cela ne concerne que le démarrage.

Dernière modification par FrancisFDZ (Le 01/12/2021, à 09:44)

ft · Le 01/12/2021, à 10:02

Oui mais justement c'est cette option qui ne fonctionne pas en ce moment, le mdp semble réinitialisé à celui de l'utilisateur.
Effectivement mon installation est mono utilisateur et chiffrée, donc ce mdp est carrément inutile dans mon cas.

FrancisFDZ · Le 01/12/2021, à 11:25

Peut-être simplement en suivant l'astuce du §4 du wiki seahorse ?

ft · Le 01/12/2021, à 11:49

ft a écrit :

alors que j'ai choisi (et rererechoisi) un mdp vide (= déverouillage sans mdp).

malheureusement...

geole · Le 01/12/2021, à 12:27

ft a écrit :

Effectivement mon installation est .... chiffrée, donc ce mdp est carrément inutile dans mon cas.

Bonjour.
Quel est l'intérêt d'une installation chiffrée dans ce cas?

Dernière modification par geole (Le 01/12/2021, à 12:28)

ft · Le 01/12/2021, à 13:55

Eh bien de ne pas permettre l'accès à ce trousseau à un individu, entre autres données.

Coeur Noir · Le 01/12/2021, à 15:32

( Euh… ton installation chiffrée, à partir du moment où elle est allumée, en route, n'importe qui devant elle peut accéder à tout, non ? )

J'ai aussi ce genre de problème d'accès au trousseau sur de nombreuses installations ( 18.04, 20.04 ) et Gnome, malgré « l'astuce » du mot de passe vide dans seahorse.
C'est plus rare avec d'autres environnements.

Dernière modification par Coeur Noir (Le 01/12/2021, à 15:36)

ft · Le 01/12/2021, à 15:38

Oui d'accord mais je ne vois pas ce que vient faire cette question de chiffrement de partition alors qu'on parle chiffrement du trousseau de clés.
Si mon ordi est éteint, seul un déchiffrement de la partition pourra permettre d'accéder au trousseau, non ?

Coeur Noir · Le 01/12/2021, à 16:07

Ton trousseau de clés devrait être lui-même chiffré, c'est l'intérêt de lui donner un mot de passe. Sans, les infos sont stockées en clair donc accessibles à n'importe qui ayant accès ( physique ou distant ) à la machine allumée.

Mais comme ce trousseau n'est pas toujours correctement déverrouillé à la connexion de session, on a tendance à le laisser à poil. C'est bof bof en terme de sécurité mais c'est comme ça depuis des lustres.

Effectivement le chiffrement des partitions n'est utile que sur une machine éteinte : celui qui la volerait ne saura pas accéder aux données sans déchiffrer.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#101 Le 18/11/2021, à 15:26

Re : Nouveautés dans Jammy

#102 Le 18/11/2021, à 15:30

Re : Nouveautés dans Jammy

#103 Le 18/11/2021, à 15:35

Re : Nouveautés dans Jammy

#104 Le 18/11/2021, à 16:02

Re : Nouveautés dans Jammy

#105 Le 18/11/2021, à 16:21

Re : Nouveautés dans Jammy

#106 Le 18/11/2021, à 16:53

Re : Nouveautés dans Jammy

#107 Le 18/11/2021, à 17:56

Re : Nouveautés dans Jammy

#108 Le 19/11/2021, à 18:48

Re : Nouveautés dans Jammy

#109 Le 20/11/2021, à 09:25

Re : Nouveautés dans Jammy

#110 Le 22/11/2021, à 04:29

Re : Nouveautés dans Jammy

#111 Le 22/11/2021, à 10:49

Re : Nouveautés dans Jammy

#112 Le 22/11/2021, à 18:23

Re : Nouveautés dans Jammy

#113 Le 22/11/2021, à 19:09

Re : Nouveautés dans Jammy

#114 Le 22/11/2021, à 19:41

Re : Nouveautés dans Jammy

#115 Le 24/11/2021, à 16:27

Re : Nouveautés dans Jammy

#116 Le 30/11/2021, à 19:20

Re : Nouveautés dans Jammy

#117 Le 01/12/2021, à 09:43

Re : Nouveautés dans Jammy

#118 Le 01/12/2021, à 10:02

Re : Nouveautés dans Jammy

#119 Le 01/12/2021, à 11:25

Re : Nouveautés dans Jammy

#120 Le 01/12/2021, à 11:49

Re : Nouveautés dans Jammy

#121 Le 01/12/2021, à 12:27

Re : Nouveautés dans Jammy

#122 Le 01/12/2021, à 13:55

Re : Nouveautés dans Jammy

#123 Le 01/12/2021, à 15:32

Re : Nouveautés dans Jammy

#124 Le 01/12/2021, à 15:38

Re : Nouveautés dans Jammy

#125 Le 01/12/2021, à 16:07

Re : Nouveautés dans Jammy

Pied de page des forums