Contenu | Rechercher | Menus

Annonce

DVD, clés USB et t-shirts Ubuntu-fr disponibles sur la boutique En Vente Libre

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

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

geole

Re : Nouveautés dans Jammy

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.

Hors ligne

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

Malizor

Re : Nouveautés dans Jammy

@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.


« Prouver que j'ai raison serait accorder que je puis avoir tort. »  -  Beaumarchais  ← Le premier troll ?

Hors ligne

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

geole

Re : Nouveautés dans Jammy

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.

Hors ligne

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

Coeur Noir

Re : Nouveautés dans Jammy

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/… )


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

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

geole

Re : Nouveautés dans Jammy

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)

Hors ligne

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

Malizor

Re : Nouveautés dans Jammy

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.


« Prouver que j'ai raison serait accorder que je puis avoir tort. »  -  Beaumarchais  ← Le premier troll ?

Hors ligne

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

Coeur Noir

Re : Nouveautés dans Jammy

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)


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

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

lynn

Re : Nouveautés dans Jammy

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


«C'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!»

Coluche

Hors ligne

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

FrancisFDZ

Re : Nouveautés dans Jammy

Ç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)


-- On peut avoir des raisons de se plaindre et n'avoir pas raison de se plaindre --
[Victor Hugo]

Hors ligne

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

Poun64

Re : Nouveautés dans Jammy

Bonsoir toul'monde !

lynn a écrit :

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

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)


Xubuntu 20.04._LTS + Windows 10 - Gigabyte GA H77M - Intel Core I7 3770K / Ivy Bridge - 4 cœurs - 3,5 Ghz - 8 Go de RAM
Xubuntu 20.04._LTS + Windows 10 - ASRock N68C-GS FX - AMD Phenom X4 Quad-Core 9500 - 2,2 Ghz - GeForce 8600 GT - 4 Go de RAM
Xubuntu 20.04._LTS  - NetBook ACER TravelMate - Intel Celeron N4020 - 2 cœurs - 1,1 Ghz - 4 Go de RAM - Intel UHD Graphics 605

Hors ligne

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

geole

Re : Nouveautés dans Jammy

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.

Hors ligne

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

Poun64

Re : Nouveautés dans Jammy

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.


Xubuntu 20.04._LTS + Windows 10 - Gigabyte GA H77M - Intel Core I7 3770K / Ivy Bridge - 4 cœurs - 3,5 Ghz - 8 Go de RAM
Xubuntu 20.04._LTS + Windows 10 - ASRock N68C-GS FX - AMD Phenom X4 Quad-Core 9500 - 2,2 Ghz - GeForce 8600 GT - 4 Go de RAM
Xubuntu 20.04._LTS  - NetBook ACER TravelMate - Intel Celeron N4020 - 2 cœurs - 1,1 Ghz - 4 Go de RAM - Intel UHD Graphics 605

Hors ligne

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

lynn

Re : Nouveautés dans Jammy

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.


«C'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!»

Coluche

Hors ligne

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

Poun64

Re : Nouveautés dans Jammy

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...


Xubuntu 20.04._LTS + Windows 10 - Gigabyte GA H77M - Intel Core I7 3770K / Ivy Bridge - 4 cœurs - 3,5 Ghz - 8 Go de RAM
Xubuntu 20.04._LTS + Windows 10 - ASRock N68C-GS FX - AMD Phenom X4 Quad-Core 9500 - 2,2 Ghz - GeForce 8600 GT - 4 Go de RAM
Xubuntu 20.04._LTS  - NetBook ACER TravelMate - Intel Celeron N4020 - 2 cœurs - 1,1 Ghz - 4 Go de RAM - Intel UHD Graphics 605

Hors ligne

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

lynn

Re : Nouveautés dans Jammy

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

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


«C'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!»

Coluche

Hors ligne

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

ft

Re : Nouveautés dans Jammy

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.


Thinkpad P14s AMD, Ubuntu 22.04

Hors ligne

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

FrancisFDZ

Re : Nouveautés dans Jammy

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)


-- On peut avoir des raisons de se plaindre et n'avoir pas raison de se plaindre --
[Victor Hugo]

Hors ligne

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

ft

Re : Nouveautés dans Jammy

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.


Thinkpad P14s AMD, Ubuntu 22.04

Hors ligne

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

FrancisFDZ

Re : Nouveautés dans Jammy

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


-- On peut avoir des raisons de se plaindre et n'avoir pas raison de se plaindre --
[Victor Hugo]

Hors ligne

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

ft

Re : Nouveautés dans Jammy

ft a écrit :

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

malheureusement...


Thinkpad P14s AMD, Ubuntu 22.04

Hors ligne

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

geole

Re : Nouveautés dans Jammy

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)

Hors ligne

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

ft

Re : Nouveautés dans Jammy

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


Thinkpad P14s AMD, Ubuntu 22.04

Hors ligne

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

Coeur Noir

Re : Nouveautés dans Jammy

( 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)


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

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

ft

Re : Nouveautés dans Jammy

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 ?


Thinkpad P14s AMD, Ubuntu 22.04

Hors ligne

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

Coeur Noir

Re : Nouveautés dans Jammy

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.


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne