La mise en cache des informations d'identification sudo est activée par défaut
Vient d’installer ubuntu 12.04 minimal, puis xfce4 et xinit à partir de la ligne de commande après le premier démarrage. Installation totalement vanille autant que je sache.
Je remarque que Sudo met le mot de passe en cache jusqu'à ce que je lance Sudo -k pour le supprimer.
C'est un comportement inattendu dans mon esprit. J'ai déjà utilisé xfce4 et je ne me souviens pas de la mise en cache des informations d'identification, pas plus que de l'expérience dans les nombreuses installations ubuntu que j'ai eues au fil des ans.
Est-ce une nouvelle fonctionnalité d'Ubuntu? Est-ce quelque chose qui est le résultat de l'installation minimale? S'agit-il d'un défaut xfce ajouté récemment?
Il cache en fait le droit d’élévation, mais pas votre mot de passe, et le fait depuis un certain temps. Cependant, il ne le fait que pour quinze minutes , par défaut. C'est par conception:
De http://linux.die.net/man/8/Sudo :
Une fois qu'un utilisateur a été authentifié, un horodatage est mis à jour et l'utilisateur peut alors utiliser Sudo sans mot de passe pendant une courte période (5 minutes, à moins d'indication contraire dans les sudoers).
et comme note de sécurité de homme sudoers :
Sudo vérifiera la propriété de son répertoire d'horodatage (/ var/db/Sudo par défaut) et ignorera le contenu du répertoire s'il n'appartient pas à root ou s'il est accessible en écriture à un utilisateur autre que root. Sur les systèmes qui permettent aux utilisateurs non root de donner des fichiers via chown (2), si le répertoire d'horodatage est situé dans un répertoire accessible en écriture (par exemple,/tmp), il est possible pour un utilisateur de créer le répertoire d'horodatage. avant que Sudo ne soit exécuté. Cependant, étant donné que Sudo vérifie la propriété et le mode du répertoire et de son contenu, le seul dommage que l’on puisse faire est de "masquer" les fichiers en les plaçant dans le répertoire horodatage. Il est peu probable que cela se produise, car une fois que le répertoire d'horodatage appartient à root et est inaccessible à tout autre utilisateur, l'utilisateur qui y place les fichiers ne peut plus les récupérer. Pour résoudre ce problème, vous pouvez utiliser un répertoire non inscriptible dans le monde pour les horodatages (/ var/adm/Sudo, par exemple) ou créer/var/db/Sudo avec le propriétaire (racine) et les autorisations appropriés (0700). dans les fichiers de démarrage du système.
et de la même page:
Comme les fichiers d'horodatage résident dans le système de fichiers, ils peuvent survivre à la session de connexion d'un utilisateur. En conséquence, un utilisateur peut être capable de se connecter, d'exécuter une commande avec Sudo après authentification, de se déconnecter, de se reconnecter et d'exécuter Sudo sans s'authentifier tant que l'heure de modification du fichier d'horodatage est de moins de 5 minutes (ou quel que soit le délai défini). à sudoers). Lorsque l'option tty_tickets est activée dans sudoers, l'horodatage a une granularité parfaite mais peut néanmoins survivre à la session de l'utilisateur. Sur les systèmes Linux où le système de fichiers devpts est utilisé, les systèmes Solaris avec le système de fichiers des périphériques, ainsi que sur les autres systèmes utilisant un système de fichiers devfs qui augmente de manière monotone le nombre d'inodes au fur et à mesure de leur création (tels que Mac OS X), Sudo peut pour déterminer quand un fichier d'horodatage basé sur tty est périmé et l'ignorera. Les administrateurs ne doivent pas compter sur cette fonctionnalité car elle n'est pas universellement disponible.
Comme on le voit ici , ce comportement persiste depuis longtemps.
Si vous souhaitez modifier cela, utilisez visudo pour définir l'option timestamp_timeout.