Contenu | Rechercher | Menus

Annonce

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.

#1 Le 14/12/2018, à 12:39

Arbiel

[Résolu] Ouverture de gedit pour le moins surprenante

[Édit]
Voir ici
[/Édit]
Bonjour

L'ouverture de gedit en mode console

gedit

aboutit à une fenêtre dont le fond est la copie de l'écran courant.

À la suite de quoi, un double clic sur un fichier textuel provoque la surimpression du texte dans la fenêtre, c'est-à-dire sur l'image déjà présente du fond d'écran.

L'ouverture d'un fichier textuel supplémentaire par la commande ouvrir du logiciel aboutit à la surimpression du nouveau fichier sur l'écran précédent.

Les divers textes qui se superposent les uns aux autres sont tous dans une couleur différente (pour permettre à l'utilisateur de les repérer plus facilement ?)

Enfin la navigation avec la molette de la souris vers la fin des fichiers ainsi ouverts provoque la surimpression des nouvelles lignes sur les anciennes.

Merci l'avance à quiconque pourra me permettre de résoudre ce problème, dont je n'ai pas su trouver trace sur le forum avant d'ouvrir le présente discussion.

Arbiel

Dernière modification par Arbiel (Le 15/12/2018, à 02:48)


Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.

Hors ligne

#2 Le 14/12/2018, à 13:12

nam1962

Re : [Résolu] Ouverture de gedit pour le moins surprenante

Ce serait plus fastoche avec du contexte :

gedit --version
cat /etc/apt/sources.list
ls /etc/apt/sources.list.d -1
ls -l /usr/share/xsessions

Dernière modification par nam1962 (Le 14/12/2018, à 13:22)


[ Modéré ]

Hors ligne

#3 Le 14/12/2018, à 14:24

Arbiel

Re : [Résolu] Ouverture de gedit pour le moins surprenante

Désolé de ne pas avoir passé ces commandes spontanément. Mais je n'aurais pas pensé à lister les informations sur les dépots.

remi@remi-Vostro-3550:~$ gedit --version
gedit - Version 3.28.1
remi@remi-Vostro-3550:~$ cat /etc/apt/sources.list
# deb cdrom:[Ubuntu 18.04.1 LTS _Bionic Beaver_ - Release amd64 (20180725)]/ bionic main restricted

# See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
# newer versions of the distribution.
deb http://fr.archive.ubuntu.com/ubuntu/ bionic main restricted
# deb-src http://fr.archive.ubuntu.com/ubuntu/ bionic main restricted

## Major bug fix updates produced after the final release of the
## distribution.
deb http://fr.archive.ubuntu.com/ubuntu/ bionic-updates main restricted
# deb-src http://fr.archive.ubuntu.com/ubuntu/ bionic-updates main restricted

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team. Also, please note that software in universe WILL NOT receive any
## review or updates from the Ubuntu security team.
deb http://fr.archive.ubuntu.com/ubuntu/ bionic universe
# deb-src http://fr.archive.ubuntu.com/ubuntu/ bionic universe
deb http://fr.archive.ubuntu.com/ubuntu/ bionic-updates universe
# deb-src http://fr.archive.ubuntu.com/ubuntu/ bionic-updates universe

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu 
## team, and may not be under a free licence. Please satisfy yourself as to 
## your rights to use the software. Also, please note that software in 
## multiverse WILL NOT receive any review or updates from the Ubuntu
## security team.
deb http://fr.archive.ubuntu.com/ubuntu/ bionic multiverse
# deb-src http://fr.archive.ubuntu.com/ubuntu/ bionic multiverse
deb http://fr.archive.ubuntu.com/ubuntu/ bionic-updates multiverse
# deb-src http://fr.archive.ubuntu.com/ubuntu/ bionic-updates multiverse

## N.B. software from this repository may not have been tested as
## extensively as that contained in the main release, although it includes
## newer versions of some applications which may provide useful features.
## Also, please note that software in backports WILL NOT receive any review
## or updates from the Ubuntu security team.
deb http://fr.archive.ubuntu.com/ubuntu/ bionic-backports main restricted universe multiverse
# deb-src http://fr.archive.ubuntu.com/ubuntu/ bionic-backports main restricted universe multiverse

## Uncomment the following two lines to add software from Canonical's
## 'partner' repository.
## This software is not part of Ubuntu, but is offered by Canonical and the
## respective vendors as a service to Ubuntu users.
# deb http://archive.canonical.com/ubuntu bionic partner
# deb-src http://archive.canonical.com/ubuntu bionic partner

deb http://security.ubuntu.com/ubuntu bionic-security main restricted
# deb-src http://security.ubuntu.com/ubuntu bionic-security main restricted
deb http://security.ubuntu.com/ubuntu bionic-security universe
# deb-src http://security.ubuntu.com/ubuntu bionic-security universe
deb http://security.ubuntu.com/ubuntu bionic-security multiverse
# deb-src http://security.ubuntu.com/ubuntu bionic-security multiverse
remi@remi-Vostro-3550:~$ ls /etc/apt/sources.list.d -1
remi@remi-Vostro-3550:~$ ls -l /usr/share/xsessions

Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.

Hors ligne

#4 Le 14/12/2018, à 15:11

nam1962

Re : [Résolu] Ouverture de gedit pour le moins surprenante

Rien de spécial dans tes dépôts et ta version est la bonne.
Par contre curieux de ne pas avoir le retour de la dernière commande

...sinon, as-tu testé en changeant de thème de bureau ?

Dernière modification par nam1962 (Le 14/12/2018, à 15:16)


[ Modéré ]

Hors ligne

#5 Le 14/12/2018, à 22:52

Arbiel

Re : [Résolu] Ouverture de gedit pour le moins surprenante

Bonsoir

Ne sachant pas avec précision ce que recouvre le terme "thème du bureau", j'ai peur de répondre à côté de la plaque. J'ai changé le fond d'écran de veille. Pour voir si cette modification pouvait avoir un impact quelconque, après ton précédent message, je suis  revenu au fond d'écran initial, sans modification aucune du comportement de gedit.

Par contre, une commande telle que

sudo gedit …

présente un écran tout à fait normal, alors que ce n'est pas le cas pour

gedit …

Dernière modification par Arbiel (Le 14/12/2018, à 22:54)


Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.

Hors ligne

#6 Le 14/12/2018, à 23:07

Coeur Noir

Re : [Résolu] Ouverture de gedit pour le moins surprenante

gedit n'est pas trop connu pour créer des problèmes insurmontables lancé via sudo, mais ça reste fortement déconseillé.

Aurais-tu lancé d'autres appli's « graphiques » avec sudo ( par ex. nautilus ) ? Là ça pourrait être beaucoup plus embêtant…

Si besoin de gedit en mode administrateur préfère :

sudo -H gedit /chemin_vers/fichier

ou

gedit admin:///chemin_vers/fichier

( l'une des 2 solutions est probablement meilleure que l'autre, éclairage bienvenu… )

Un usage malheureux d'appli's graphiques en mode administrateur peut changer les propriétaires de certains fichiers/dossiers,
on peut déjà jeter un œil à ça :

ls -la ~

…si tu vois root au lieu de ton nom d'utilisateur comme propriétaires de certains fichiers, il faudra creuser cette piste.

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


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

Hors ligne

#7 Le 14/12/2018, à 23:13

Roschan

Re : [Résolu] Ouverture de gedit pour le moins surprenante

Arbiel a écrit :

Par contre, une commande telle que

sudo gedit …

Et allez, encore un champion.

nam t'abuses à le laisser ramer et à lui demander ses sources, des amateurs de sudo gedit qui ont une fenêtre transparente il y en a déjà eu 5 ou 6 en quelques mois, et à chaque fois le souci était le même et la réparation était la même : aller dans les préférences de gedit et mettre un thème de coloration du code qui existe (Kate, Oblivion, ...).

Hors ligne

#8 Le 14/12/2018, à 23:18

Coeur Noir

Re : [Résolu] Ouverture de gedit pour le moins surprenante

Sauf que là Roschan le sudo gedit s'affiche normalement mais pas le simple gedit… d'où mon autre supposition.


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

Hors ligne

#9 Le 14/12/2018, à 23:52

Roschan

Re : [Résolu] Ouverture de gedit pour le moins surprenante

Ouais ok, du coup c'est exactement comme dans les autres cas dont je parle. Et c'est la même solution.

Je pointe simplement le HASARD qu'il y a à constater que les gens avec ce problème sont souvent par pure COÏNCIDENCE les mêmes que ceux qui font n'importe quoi avec les commandes.

Hors ligne

#10 Le 15/12/2018, à 00:24

Watael

Re : [Résolu] Ouverture de gedit pour le moins surprenante

qu'on leur coupe les mains !!! lol


Connected \o/
Welcome to sHell. · eval is evil.

Hors ligne

#11 Le 15/12/2018, à 01:24

Coeur Noir

Re : [Résolu] Ouverture de gedit pour le moins surprenante

Votre sens de la pédagogie m'échappe…


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

Hors ligne

#12 Le 15/12/2018, à 01:37

bluc

Re : [Résolu] Ouverture de gedit pour le moins surprenante

Bonjour,

Le type qui n'est pas en permanence sur les forums, il va savoir comment qu'il ne faut plus utiliser sudo en graphique , alors que pendant 10 - 15 ans on a toujours employé sudo pour nautilus ou gedit sans problèmes
il y en a qui ont une vie a coté de Linux !...

Dernière modification par bluc (Le 15/12/2018, à 01:42)


Clevo :  Ubuntu 23.10   ❖  Xubuntu 22.10  ❖  Kubuntu 23.10   
         avec partition data commune       Une fraction de seconde                    Multiboot

Hors ligne

#13 Le 15/12/2018, à 01:50

Arbiel

Re : [Résolu] Ouverture de gedit pour le moins surprenante

Il se trouve qu'en mode utilisateur, ma version de gedit 3.28.1 ne fonctionne pas correctement, alors qu'il semble fonctionner beaucoup mieux en mode administrateur.

Le changement de couleur ne résout pas le problème de la présentation de la fenêtre, qui, soit répété en passant, n'est absolument pas transparente, mais est la copie d'écran au moment de la commande. Qui plus est, le menu de contrôle, en mode utilisateur, est incomplet, et incohérent. Il conduit même à un blocage de la fenêtre.

J'ai bien vérifié que les fichiers de mon espace personnel comme ceux de mon bureau ne sont pas devenus la propriété de l'administrateur, bien qu'il m'arrive d'utiliser sudo en mode administrateur pour modifier des fichiers sensibles tels que fstab, crypttab ou même grub.cfg. Je ne vois pas bien en quoi cette pratique, même si elle comporte des risques de blocage du système, devrait détériorer le fonctionnement de sudo en mode utilisateur.

Il m'arrive d'utiliser sudo en mode administrateur avec nautilus ou geany.

Je n'ai jamais eu d'ennui avec nautilus, ce qui ne signifie pas que je pourrais en avoir à l'avenir. J'ai bien noté ici ou là les recommandations d'éviter cette pratique, mais jamais aucune présentation des risques réels. Que les ennuis se limitent à faire que l'administrateur devienne le propriétaire de mes fichiers ne me paraît pas vraiment un risque majeur.

Avec geany, j'ai rencontré une difficulté dont Tiramiseb m'avait tiré.

Je vous remercie d'avoir essayé de m'aider, et je vais continuer de chercher quelle peut être l'origine de cette bizarrerie.

Je ne suis pas vraiment gêné d'utiliser gedit en mode administrateur pour modifier mes propres fichiers si je ne trouve aucune autre solution.

Dernière modification par Arbiel (Le 15/12/2018, à 02:12)


Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.

Hors ligne

#14 Le 15/12/2018, à 02:07

bluc

Re : [Résolu] Ouverture de gedit pour le moins surprenante

Et si tu fais par exemple pour fstab

gedit admin:///etc/fstab

Clevo :  Ubuntu 23.10   ❖  Xubuntu 22.10  ❖  Kubuntu 23.10   
         avec partition data commune       Une fraction de seconde                    Multiboot

Hors ligne

#15 Le 15/12/2018, à 02:15

Arbiel

Re : [Résolu] Ouverture de gedit pour le moins surprenante

Mais mon problème n'est pas comment utiliser gedit en mode administrateur, mais pourquoi il m'est impossible de l'utiliser en mode utilisateur. Car, dans ce mode, comme je l'ai présenté en ouvrant cette discussion, il est inutilisable.


Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.

Hors ligne

#16 Le 15/12/2018, à 02:38

Arbiel

Re : [Résolu] Ouverture de gedit pour le moins surprenante

La solution est ici
Il s'avère que lors de la mise en œuvre de mon clavier pour la saisie du grec polytonique façon bépo, le fichier ~/.xinputrc s'est trouvé être erroné. Je l'ai modifié en en commentant les diverses lignes, au lieu de le détruire.

Dernière modification par Arbiel (Le 15/12/2018, à 12:16)


Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.

Hors ligne

#17 Le 15/12/2018, à 16:19

Coeur Noir

Re : [Résolu] Ouverture de gedit pour le moins surprenante

bluc a écrit :

pendant 10 - 15 ans on a toujours employé sudo pour nautilus ou gedit sans problèmes

Euh non bluc : gksudo ou kdesudo à la rigueur pour lancer des appli's graphiques en administrateur… mais c'est déprécié en vue du passage hypothétique à wayland par défaut ( sous wayland seul l'utilisateur courant a accès à la partie graphique ).

Arbiel a écrit :

les recommandations d'éviter cette pratique, mais jamais aucune présentation des risques réels. Que les ennuis se limitent à faire que l'administrateur devienne le propriétaire de mes fichiers ne me paraît pas vraiment un risque majeur.

Ça dépend grandement de l'appli lancée via sudo. Et de ce qui est fait avec cette appli.
La première conséquence c'est root qui s'approprie des fichiers. S'il ne s'agit que de documents perso, c'est assez simple de se les réapproprier.
Si ce sont des fichiers de config' ( dans ~/.config ou ~/.local ou ~/.gvfs ou ~/.dbus ou ~/.gvfs ou les fichiers .ICEauthority ou .Xauthority… ) ça peut ensuite perturber le fonctionnement d'autres appli's, voire empêcher une ouverture de session graphique.
Or une appli' graphique utilise quasiment toujours davantage qu'un seul fichier : si ce n'est qu'en lecture peu de risque ( ce qui explique que sudo nautilus ou sudo gedit ne posent pas systématiquement problème ) mais dès qu'il y a une écriture, ça peut avoir beaucoup de conséquences, dont des blocages.

Exemple, lancer LibreOffice ou Gimp en sudo : pas sûr qu'au lancement normal suivant depuis l'utilisateur courant, cet utilisateur ait encore accès aux config's de ces logiciels devenues la propriété de root à cause du lancement précédent. Autre exemple : te viendrait-il à l'idée de lancer un navigateur web ou un gestionnaire de téléchargements en sudo ? Le risque sécuritaire paraît assez évident ( des fichiers exécutables téléchargés qui seraient propriété de root, chic si ce sont des programmes malveillants )…

Ton fichier .xinputrc n'appartenait-il pas à root par hasard ? En le modifiant tu te l'es peut-être réapproprié ?

En gros tout ce qui est dans le répertoire personnel de toto est censé appartenir à l'utilisateur toto - et par défaut sous Ubuntu au groupe du même nom.
Vérifiable via

ls -la ~
ls -la ~/.config
ls -la ~/.local/share

S'il faut tout lui réapproprier là dedans ce sera

cd /home
sudo chown -R toto:toto toto

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

Hors ligne

#18 Le 15/12/2018, à 20:02

Arbiel

Re : [Résolu] Ouverture de gedit pour le moins surprenante

Bonsoir

Je comprends ce qui peut arriver en utilisant des commandes graphiques en mode administrateur. C'est d'ailleurs ce qui m'était arrivé avec geany. Mais je n'ai jamais eu de tels déboires avec gedit ni avec nautilus. Je vais dorénavant être plus prudent, d'autant que j'ai pris l'habitude, lorsque je veux enregistré un fichier protégé que j'ai modifié en mode utilisateur, de l'enregistrer dans /tmp puis de le recopier à sa place avec "sudo cp -t …", ce qui d'ailleurs m'évite de passer pas "sudo nautilus".

Pour ce qui concerne les fichiers de ~, bon nombre sont ma propriété, mais propriété du groupe root, dont je suis membre. Je ne pense pas qu'il soit nécessaire d'en modifier les propriétés. Certains sont propriétés de root

remi@remi-Vostro-3550:~$ alias test='liste () { echo $1; ls -la  $1 | grep -v remi ; } ; liste '
remi@remi-Vostro-3550:~$ test ~
/home/remi
total 631112
-rw-r--r--   1 root root       195 juin  14  2018 .bash_profile
-rw-rwxr--   1 1002 root      3675 juin  14  2018 .bashrc
dr-x------   2 root root      4096 juin   3  2015 .gvfs
-r--------   1 root root   2066432 juin  28  2015 lhs
-rw-r--r--   1 root root       864 juin  14  2018 .profile
-rw-r--r--   1 root root         0 juil. 20  2016 .sudo_as_admin_successful
remi@remi-Vostro-3550:~$ test ~/.config
/home/remi/.config
total 296
drwx------  2 root root 4096 août   7  2016 enchant
remi@remi-Vostro-3550:~$ test ~/.local/share
/home/remi/.local/share
total 272
drwxr-xr-x  2 root root  4096 mai   22  2017 inxi
remi@remi-Vostro-3550:~$ 

J'ai donné propriété de mon dossier lhs pour éviter d'y entrer par mégarde.

Pour les autres, te semble-t-il nécessaire que j'en change le propriétaire ?

Enfin, pour ce qui est du fichier   ~/.xinputrc, je l'ai détruit sans mémoriser les droits qui lui étaient attachés. J'en ai créé un nouveau, vide, sans aucune conséquence sur le fonctionnement de gedit.


Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.

Hors ligne

#19 Le 15/12/2018, à 23:22

Coeur Noir

Re : [Résolu] Ouverture de gedit pour le moins surprenante

Ouh là…

  1. Pourquoi ton utilisateur « normal » remi ferait-il partie du groupe root, d'où vient cette très mauvaise idée ?

  2. Oui tous devraient appartenir à remi:remi !
    C'est vraiment pas étonnant que ton gedit ait eu du mal à fonctionner hors sudo avec ceux-là [ .bash_profile .bashrc .gvfs .profile .sudo_as_admin_successful ] appartenant à root.
    Pour enchant, inxi à priori l'utilisateur remi doit avoir bien du mal à utiliser les logiciels en question - quoi qu'en ayant mis remi dans le groupe root ça contourne peut-être le souci mais en ajoutant une bonne grosse brèche de sécurité !

  3. Pourquoi voit-on un utilisateur 1002, un ancien qui a été supprimé depuis ?

  4. Enfin .xinputrc n'est pas un fichier vide à priori, voici ce que j'y trouve :

    # im-config(8) generated on Sat, 02 Jun 2018 21:52:21 +0200
    run_im ibus
    # im-config signature: 5x2x47x1ex12x92x24xe7x33x8ex95x0c  -

    …forte chance qu'il soit généré automatiquement.

Dernière modification par Coeur Noir (Le 15/12/2018, à 23:29)


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

Hors ligne

#20 Le 16/12/2018, à 00:28

Arbiel

Re : [Résolu] Ouverture de gedit pour le moins surprenante

Effectivement, remi ne fait pas partie de root

remi@remi-Vostro-3550:~$ cat /etc/group | grep root
root:x:0:
remi@remi-Vostro-3550:~$ 

Une des raisons pour lesquelles des fichiers ou des répertoires peuvent être la propriété de root est le désir de les protéger de toute erreur de manipulation. Le fait de devoir passer par sudo est un moyen de forcer l'attention. L'important n'est-il pas que tous les utilisateurs puissent lire ces fichiers ? Dans les fichiers et répertoires que j'ai mis en évidence, il n'y a que .gvfs (et, volontairement, mon répertoire lhs) qui ne soit pas accessible en lecture. Je crois que gfvs est utilisé par nautilus, et je n'ai eu jusqu'à présent aucun souci avec lui, malgré l'absence de droit en lecture.

Mais tout cela n'a a priori rien à voir avec le problème de gedit. C'est la simple suppression du fichier xinputrc qui a permis de revenir à un fonctionnement normal. En début de soirée, je l'ai recréé en l'attribuant a root puis à remi, avec ou sans droit d'exécution, sans que cela ne perturbe gedit. Je l'ai à nouveau supprimé.

remi@remi-Vostro-3550:~$ ls ~/.xinputrc
ls: impossible d'accéder à '/home/remi/.xinputrc': Aucun fichier ou dossier de ce type
remi@remi-Vostro-3550:~$ 

Dans mon souvenir, lorsque je suis intervenu dessus, il m'a semblé être exécuté à l'ouverture de la session utilisateur. Il contenait quelques lignes dont deux seulement n'étaient pas commentées, et qui m'ont paru être des lignes bash dont le début avait été tronqué. Comme je l'ai indiqué précédemment, j'ai commenté ces deux lignes. Il reste pour moi tout à fait incompréhensible que la présence d'un tel fichier ait pu avoir un impact quelconque. Le retour à un fonctionnement normal ne résulte que de la suppression du fichier comme l'indique l'intervention que j'ai lue sur "askubuntu", intervention qui montre que le problème ne m'était pas spécifique.

L'utilisateur 1002 a effectivement disparu.

Je ne sais pas ce que sont enchant et inxi, peut-être le résidu de tests anciens.

[Édit]

Lorsque j'ai écrit mon clavier graphique pour la saisie de grec polytonique (grec ancien) façon bépo, j'ai eu recours au site bépo pour rendre effectif le fichier .XCompose, absolument nécessaire pour la prise en compte des diacritiques. On m'y a conseillé de passer la commande ci-dessous

remi@remi-Vostro-3550:~$ ls ~/.xinputrc
ls: impossible d'accéder à '/home/remi/.xinputrc': Aucun fichier ou dossier de ce type
remi@remi-Vostro-3550:~$ im-config -n xim
remi@remi-Vostro-3550:~$ ls ~/.xinputrc
/home/remi/.xinputrc
remi@remi-Vostro-3550:~$ cat ~/.xinputrc
# im-config(8) generated on Sun, 16 Dec 2018 00:29:34 +0100
run_im xim
# im-config signature: 022dabffb1674184aab07d4f94157de5  -
remi@remi-Vostro-3550:~$ gedit
remi@remi-Vostro-3550:~$ 

Aucun effet négatif sur gedit

Dernière modification par Arbiel (Le 16/12/2018, à 00:36)


Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.

Hors ligne

#21 Le 16/12/2018, à 00:47

Watael

Re : [Résolu] Ouverture de gedit pour le moins surprenante

cat /etc/group | grep root

non.

grep root /etc/group

ou

getent group root

Connected \o/
Welcome to sHell. · eval is evil.

Hors ligne

#22 Le 16/12/2018, à 01:31

Coeur Noir

Re : [Résolu] Ouverture de gedit pour le moins surprenante

Pour voir à quels groupes est associé l'utilisateur courant, la commande

id

Le fichier .xinputrc sert à enregistrer la méthode de saisie ( fcitx, ibus, yong… ) choisie par l'utilisateur, donc c'est normal que ce fichier existe, voire revienne même après suppression dès lors qu'une méthode de saisie est renseignée ( souvent dans paramètres, prise en charge des langues ).

Une des raisons pour lesquelles des fichiers ou des répertoires peuvent être la propriété de root est le désir de les protéger de toute erreur de manipulation. Non. Les fichiers appartenant à root sont des fichiers systèmes. Point barre. Je comprends l'idée mais du coup passer en root qui permet de faire tout et n'importe quoi partout dans le système, juste pour récupérer l'accès à un fichier ne me paraît guère plus prudent !
Il me vient 2 idées pour « protéger » un fichier sans changer de propriétaire ni passer par root :
⋅ le cacher, voir https://doc.ubuntu-fr.org/fichier_cache
⋅ lui enlever le droit d'écriture à tout le monde, voir https://doc.ubuntu-fr.org/droits et https://doc.ubuntu-fr.org/permissions et ne le remettre qu'en cas de besoin de modification.

Concernant la solution trouvée sur askubuntu, on a aucune idée du contexte : ça se trouve comme toi Hedonistoic avait aussi .bash, .bashrc, .profile appartenant à root… cherche à quoi servent ces fichiers et tu comprendras tout seul quelle importance ils peuvent avoir pour gedit ou nautilus et bien d'autres.

il n'y a que .gvfs (et, volontairement, mon répertoire lhs) qui ne soit pas accessible en lecture. Je crois que gfvs est utilisé par nautilus, et je n'ai eu jusqu'à présent aucun souci avec lui, malgré l'absence de droit en lecture.
Euh… r pour read = lecture, w pour write = écriture, x pour execute = exécution. Donc .gvfs chez toi accorde les droits lecture + exécution à son utilisateur propriétaire. Chez moi ça n'est pas comme chez toi ( rwx ).
Pour ton répertoire lhs, voir un peu plus haut concernant cacher / ou droits. En tout cas aucun intérêt à le donner à root ça ne relève d'aucune logique ( c'est ton répertoire à toi Rémi, ça n'est pas un élément du système ).

Bref on ne va pas réinventer Linux / unix. C'est un système fondamentalement basé sur la multiplicité des utilisateurs et groupes, donc les questions de droits et permissions y sont fondamentales : la séparation entre ce qui relève de root ( le système ) et d'autres utilisateurs ( humains, avec leurs documents personnels ) est un des éléments clé de la sécurité de l'ensemble.

Donc ce que fait Rémi, appartient à remi:remi, se range dans /home/remi et seul Rémi y a accès. C'est sain. Je réitère le :

cd /home
sudo chown -R remi:remi remi

J'irais même jusqu'à :

sudo chmod -R a-w,a+rX,u+rwX remi

si personne n'y voit de bêtise flagrante.
X plutôt que x → exécution sur les dossiers ( obligatoire ) pas sur les fichiers ( au cas par cas pour les scripts, lanceurs et programmes… ) le chmod que je propose ne touche pas aux droits d'exécution déjà existants.
a-w → enlève à tous ( a = all soit user, group et other ) le droit écriture puis
a+rX → ajoute à tous lecture et exécution ( sur les dossiers ) puis
u+rwX → ajoute à l'utilisateur propriétaire lecture, écriture et eXécution.

Maintenant si cet ordinateur est utilisé par plusieurs humains, il faut peut-être songer à créer diverses sessions utilisateurs, et organiser les partages de données plus finement : c'est tout l'intérêt des groupes, droits et permissions.
Es-tu dans un tel contexte ? Si oui ça peut faire l'objet d'un nouveau fil de discussion…

Dernière modification par Coeur Noir (Le 16/12/2018, à 02:09)


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

Hors ligne

#23 Le 19/12/2018, à 08:10

moko138

Re : [Résolu] Ouverture de gedit pour le moins surprenante

Arbiel, je découvre tardivement ton fil et je suis stupéfait qu'une personne soucieuse de sécurité et de confidentialité comme tu l'es depuis des années, par ailleurs auteur de scripts pointus, prenne le risque d'employer sudo avec des applications graphiques.


Pour ton "alias test", il omet les sous-répertoires. Je t'invite à tester cette variante :

ls -laR ~ | grep " root "

= =

     À tous,
Plutôt que chown -Rv, que j'ai longtemps indiqué, je préfère

sudo chown -Rc $USER:$USER /home/$USER

à copier-coller tel quel,
qui montre tous les éléments modifiés par chown, et seulement eux.


Après ce rétablissement du propriétaire correct,

chmod a-w est en effet simple et efficace pour protéger un élément d'écritures malencontreuses :

chmod -R a-w /home/$USER/mon-répertoire
chmod a-w /home/$USER/mon-fichier

= =

     À Arbiel,
Donc pour ton fichier lhs, finir par : chmod a-w /home/remi/lhs


%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel :  À la découverte de dcraw

Hors ligne

#24 Le 24/12/2018, à 11:45

Arbiel

Re : [Résolu] Ouverture de gedit pour le moins surprenante

Bonjour

Merci à vous pour vos conseils et explications. Ils m'amènent à réfléchir sur l'organisation de mes documents et à m'interroger sur son impact sur la sécurité de mon système.

J'ai effectivement insuffisamment tenu compte des possibilités offertes par les droits. J'ai néanmoins du mal à distinguer en quoi l'utilisation abusive de "root" affaiblit la sécurité de mon système. La présente discussion n'étant pas l'endroit idéal pour en discuter, j'en ouvrirai probablement une autre dès que j'aurai réussi la migration de la 14.04 à la 18.04 qui me cause quelques difficultés, elles aussi, hors sujet.

J'ai bien compris la réticence de nombre d'entre vous à l'utilisation de sudo avec les applications graphiques, utilisation susceptible de provoquer des dysfonctionnements à droite ou à gauche et, en conséquence, une perte de temps pour y remédier. Mais :

remi@remi-Vostro-3550:~$ uname -a
Linux remi-Vostro-3550 4.15.0-43-generic #46-Ubuntu SMP Thu Dec 6 14:45:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
remi@remi-Vostro-3550:~$ gksudo cat /etc/fstab

La commande « gksudo » n'a pas été trouvée, voulez-vous dire :

  commande « gfsudo » du deb gfarm-client

Essayez : sudo apt install <nom du deb>

remi@remi-Vostro-3550:~$ kdesudo cat /etc/fstab
kdesudo : commande introuvable
remi@remi-Vostro-3550:~$ cat admin:///etc/fstab
cat: 'admin:///etc/fstab': Aucun fichier ou dossier de ce type
remi@remi-Vostro-3550:~$ ls -l /etc/fstab
-rw-r--r-- 1 root root 4056 déc.  17 22:01 /etc/fstab
remi@remi-Vostro-3550:~$ 

me laisse perplexe.

Bonnes fêtes de fin d'année à tous.


Arbiel Perlacremaz
LDLC Aurore NK3S-8-S4 Ubuntu 20.04
Abandon d'azerty au profit de bépo, de google au profit de Lilo et de la messagerie électronique violable au profit de Protonmail, une messagerie chiffrée de poste de travail à poste de travail.

Hors ligne

#25 Le 24/12/2018, à 13:04

moko138

Re : [Résolu] Ouverture de gedit pour le moins surprenante

1) Pour le successeur de gksudo,
dans ton cas, la solution est à la fin de ce message : ./viewtopic.php?pid=22023825#p22023825


  - -
2) Pour

Arbiel a écrit :

protéger de toute erreur de manipulation  (...) lhs.

à côté de chmod a-w ... j'oubliais :

sudo chattr +i /home/remi/lhs

qui te laissera propriétaire du fichier ;
et le rendra immuable.

     Le jour où tu souhaites l'éditer, tu dois d'abord retirer l'attribut "i(mmuable)" :

sudo chattr -i /home/remi/lhs

  - -


Pour en savoir plus

man chattr
      A file with the `i' attribute cannot be modified: it cannot be deleted or renamed, no link  can  be
       created  to this file and no data can be written to the file.  Only the superuser or a process pos‐
       sessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel :  À la découverte de dcraw

Hors ligne