Loging su corrompu

Support Debian
#1

Bonjour,

j’ai un problème de login en super utilisateur.
Après la commande su dans un terminal X et le renseignement du mot de passe (qui est le bon), le système affiche:
“Impossible d’exécuter q: Aucun fichier ou dossier de ce type”

Je soupçonne une fausse manipulation avec vi, qui aurait laissé dans un fichier parcouru après le login la lettre “q”.

Quels sont SVP les fichiers système parcourus après ce type de login?
Le passage en root par l’interface de changement de session, lui, se passe bien.

Merci!!

#2

Bonjour clau.s

Il y a bien le fichier caché /root/.bashrc

Mais après avoir ajouté une ligne ne contenant que la lettre q à la fin de ce fichier,
je constate que le message d’erreur retourné n’est pas le même que celui qui t’a été retourné.

michel@debg53sw:~$ su
Mot de passe : 
bash: q : commande introuvable
root@debg53sw:/home/michel#
#3

Essaye plutôt le ~/.bashrc de ton user !

#4

Bonjour AlienQueen

Si clau.s a entré la commande su sans spécifier de nom d’utilisateur,
par défaut, c’est de l’utilisateur root qu’il s’agit.

#5

Oui, en effet. Autant pour moi !

Sinon, il y a le .profile à essayer.

#6

Bonjour AlienQueen & MicP,

merci de vos suggestions!

Le su concerne bien le root, mais ni son .profile ni son .bashrc, que je viens d’ouvrir, ne contiennent de “q”.
Le su sur d’autres utilisateurs se passe bien.

#7

Oui mais pour que le fichier .profile du compte auquel il cherche à se connecter soit exécuté,
il aurait fallu qu’il utilise l’option - ou -l ou –login de la commande su

#8

Si tu as entré autre chose que seulement su (et rien d’autre dans la ligne de commande)
pourrais-tu nous donner un copié/collé de la ligne de commande complète que tu as entré,
sinon, on est obligé d’envisager toutes les possibilités, (si on en a le courage, le temps et l’envie…)

#9

Ha bon ? Tu m’en apprends, là !

#10

Clau.s : tiens, regarde là :

http://stefaanlippens.net/bashrc_and_others/

Ca devrait être un bon début.

#11 
root@debg53sw:~# cat .profile 
# ~/.profile: executed by Bourne-compatible login shells.

if [ "$BASH" ]; then
  if [ -f ~/.bashrc ]; then
    . ~/.bashrc
  fi
fi
touch /root/xxxxxxxx.txt
root@debg53sw:~# 

root@debg53sw:~# ls -l /root/xxxxxxxx.txt
ls: impossible d'accéder à /root/xxxxxxxx.txt: Aucun fichier ou dossier de ce type
root@debg53sw:~# 

root@debg53sw:~# exit
déconnexion
michel@debg53sw:~$ 

michel@debg53sw:~$ su
Mot de passe : 
root@debg53sw:/home/michel# 

root@debg53sw:/home/michel# ls -l /root/xxxxxxxx.txt
ls: impossible d'accéder à /root/xxxxxxxx.txt: Aucun fichier ou dossier de ce type
root@debg53sw:/home/michel# 

root@debg53sw:/home/michel# exit
exit
michel@debg53sw:~$ 

michel@debg53sw:~$ su -
Mot de passe : 
root@debg53sw:~# 

root@debg53sw:~# ls -l /root/xxxxxxxx.txt
-rw-r--r-- 1 root root 0 mars  25 19:36 /root/xxxxxxxx.txt
root@debg53sw:~#
#12

Merci à vous deux de vos aides et efforts,

j’ai donc fait une série de commandes su dans un terminal X:
1/
Sans option :
libres@libres:~$ su
Mot de passe :
Impossible d’exécuter q: Aucun fichier ou dossier de ce type
libres@libres:~$ whoami
libres

libres@libres:~$ su root
Mot de passe :
Impossible d’exécuter q: Aucun fichier ou dossier de ce type
libres@libres:~$ whoami
libres

2/Avec l’option - -l --login :
libres@libres:~$ su -
Mot de passe :
Impossible d’exécuter q: Aucun fichier ou dossier de ce type

libres@libres:~$ su -l
Mot de passe :
Impossible d’exécuter q: Aucun fichier ou dossier de ce type

libres@libres:~$ su --login
Mot de passe :
Impossible d’exécuter q: Aucun fichier ou dossier de ce type

3/Pour un autre utilisateur que root, ça marche :
libres@libres:~$ su user2
Mot de passe :
user2@libres:/home/libres$ whoami
user2

J’ai aussi consulté le lien suggéré par AlienQueen:
When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. => Rien de suspect dans ce fichier
After reading that file, it looks for~/.bash_profile, ~/.bash_login,
=> ceux ci sont inexistants
and ~/.profile, => Rien de suspect
in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior.

Et puis on peut normalement devenir administrateur via le menu suivant de la barre de commande :
Logiciels->Outils Système->Terminal administrateur

Voila la réponse du système:
Impossible de lancer /usr/bin/x-terminal-emulator en tant qu’utilisateur root.

Échec lors de la communication avec gksu-run-helper.

Reçu :
Impossible d’exécuter q
Ce qui était attendu :
gksu: waiting

#13

Bonjour,

Une autre approche serait de chercher ce qui a été modifié avant que ça ne fonctionne plus.
Regarder dans les fichiers .bash_history les commandes passées pour avoir une idée…
Sinon, déterminer la date à laquelle l’erreur est apparue, et faire un touch d’un fichier dans /tmp avec une date antérieure.
$ touch -t 201703200000 /tmp/ts
Ensuite faire une recherche dans les répertoires de la racine des fichiers modifiés après la date de /tmp/ts, par exemple :
# find / -mount -type f -newer /tmp/ts
Aussi puisqu’on cherche le champ “q:” faire un grep récursif dessus :

grep -r “q:”

Eventuellement combiner les 2 :
# find / -mount -type f -newer /tmp/ts -exec grep -l "q:" {} \; 2>/dev/null

N.B. : Ces commandes find recherchent uniquement sur le filesystem de la racine (/).
A voir pour étendre si besoin sur d’autre FS.

A+

#14

Bonjour

Peut-être aussi en listant les aliases avec la commande :

alias
#15

Bonjour,

un pas en avant, un (grand) en arrière…
J’ai trouvé un pb similaire sur le web, et effectivement, la première ligne de /etc/passwd était incorrecte et contenait le “q” en question, vestige peut-être d’une mauvaise sortie de vi:
root:x:0:0:root:/root:q

Et puis… une fois q remplacé par /bin/bash, et quelques essais de changements d’utilisateurs faits soit via l’interface système de changement de session soit via la commande su dans un terminal X, qui donnaient des résultats à peu près corrects, j’ai redémarré la machine.

Et ça ne va plus.

Pas de startx automatique (j’arrive à KDE en entrant la commande), pas de NetworkManager, plus de réseau ni de reconnaissance de clé USB, et j’en passe surement.

Et plus moyen du tout de se logger en root.

#16

Bonjour

Effectivement : il aurait fallu remplacer le dernier caractère de la ligne (q)
par /bin/bash

Mais en démarrant depuis un cd d’installation,
tu pourra avoir accès à la partition racine en utilisant l’option qui te permet de faire un chroot
et tu pourra faire la modification.

avec une image iso netinstall,

Advanced option -> Rescue mode

Tu démarre ta machine, tu choisis la configuration de ton clavier, etc.
et à la fin tu aura une liste des partitions accessibles
dans laquelle tu choisis ta partition racine à mounter,
et tu pourra ouvrir un shell avec cette partition mountée
pour modifier le fichier avec nano ou vi, etc.
ou bien avec la ligne de commande suivante :

sed -i 's|/root\:$|/root\:/bin/bash|' /etc/passwd
#17

Merci bien,

ces solutions permettent de préserver les diverses données enregistrées sous /home, ainsi que les logiciels et MAJ installés (un peu partout)?

#18

Bonjour

La méthode que je proposais dans mon message précédent te permet d’accéder à la partition racine de ton système afin de pouvoir modifier les fichiers que tu voudra avec les privilèges du compte root que tu ne pourra pas obtenir tant que la ligne

root:x:0:0:root:/root:/bin/bash

de ton fichier /etc/passwd naura pas été rectifiée.

Bien sûr, si tu n’entre aucune autre commande qui modifierait “les diverses données enregistrées sous /home”,
elles ne seront pas modifiées.

#19

Bonjour,

merci! J’ai utilisé un CD iso-netinstall Jessie, et ça marche pour root! :slight_smile:

Bon maintenant, les utilisateurs autres ne sont plus reconnus, “Je n’ai pas de nom!” est le retour de su toto, mais leurs /home/dossier existent et les données avec…
C’est mineur par rapport à la situation précédente.

#20

C’est Ok. Le fichier /etc/passwd avait des droits égaux à 600, il n’était donc pas lisible par un utilisateur autre que root. C’est maintenant à 644, et les logins se passent bien.

Merci à tous.