Ubuntu-fr

cricri

Perte d'accès sudo sur un serveur 12.04 LTS [Résolu]

Bonjour,

j'ai installé un serveur 12.04, LAMP, pour faire tourner des enquêtes Limesurvey.
pour la sécurité : iptables ouvre seulement les ports 80 et ssh ; j'ai installé et configuré fail2ban pour un banissement de 3 jours. je surveille les logs, en particulier auth.log.
J'ai constaté qu'ils étaient "pollués" par des entrées de connexion / déconnexion de CRON. en cherchant sur le web, j'ai trouvé sur un forum une proposition de solution que j'ai (malheureusement) mise en oeuvre.

j'ai modifié le fichier /etc/pam.d/common-session-noninteractive de la manière suivante :
sous la ligne :

session required        pam_unix.so

j'ai ajouté les deux lignes suivante :

session [success=1 default=ignore] pam_succeed_if.so service in cron
quiet use_id

résultat : la commande sudo ne marche plus.
j'ai relancé le serveur en mode dépannage, lancé une session root : j'ai la session, mais pas les droits sur le fichier, je ne peux donc pas revenir en arrière.

Je suis novice en la matière.

Quelqu'un a-t-il une idée ?

Dernière modification par cricri (Le 18/12/2013, à 12:29)

Grünt

Re : Perte d'accès sudo sur un serveur 12.04 LTS [Résolu]

"Pas les droits sur le fichier", ça ne serait pas plutôt la partition racine montée en lecture seule ?
Vérifie avec :

mount

---

Red flashing lights. I bet they mean something.

cricri

Re : Perte d'accès sudo sur un serveur 12.04 LTS [Résolu]

Le mount donne ce résultat :

admin-gcs@eSante-Bretagne1:~$ mount
/dev/sda1 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
gvfs-fuse-daemon on /home/admin-gcs/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=admin-gcs)

a priori, la première ligne dit "rw", donc je pense que ce n'est pas ça ?

oxedion

Re : Perte d'accès sudo sur un serveur 12.04 LTS [Résolu]

Le temps de cibler la source du problème, tu peux déjà récupérer ton système en boutant sur un live cd / usb et en éditant le fichier en sens inverse (en faisant un backup et en respectant les droits d'accès au fichier).

Dernière modification par oxedion (Le 18/12/2013, à 11:21)

---

Asus Maximus 6 Heros - i5 4670K - Gigabyte GTX 670 OC (Watercooling CPU + GPU)
Mon site web : http://www.spheniscus.brennik.fr

cricri

Re : Perte d'accès sudo sur un serveur 12.04 LTS [Résolu]

Je n'ai pas de problème avec le système dans son ensemble : tout fonctionne très bien, sauf la commande sudo.  Par exemple, le site LimleSurvey est toujours accessible (ce qui implique Apache OK, MySQL OK).

En revanche, il semble que l'utilisateur "root" n'aie plus les droits super admin. Par exemple, si je lance la commande "webalizer", j'obtiens des messages d'erreurs relatifs à l'ouverture et à l'écriture de fichiers ("unable to open..., unable to write...").

Dans /etc/pam.d, il y a un fichier "sudo", qui est un script. en l'éditant, j'ai vu qu'il appelle le script common-session-noninteractive, celui que j'ai modifié. Je présume donc qu'il y a une relation à ce niveau, mais je ne comprends pas laquelle.

Compte anonymisé

Re : Perte d'accès sudo sur un serveur 12.04 LTS [Résolu]

Salut

En mode dépannage, session root, en remontant le système de fichier / en rw :
mount  -o  remount,rw  /
tu n'arrives pas à faire un :
nano  /etc/pam.d/common-session-noninteractive
puis à supprimer les 2 lignes ajoutées ?

Je suis étonné, root peut faire ce que bon lui semble.

@+

cricri

Re : Perte d'accès sudo sur un serveur 12.04 LTS [Résolu]

J'ai modifié le fichier à partir d'une session de réparation système, lancée à partir d'un liveCD (merci Oxedion).
Le système m'a proposé de lancer un shell sur /dev/sdda1, et là j'ai pu modifier le fichier.

Merci pour aide.