Pourquoi konsole lit-il / etc / passwd?

Par rapport à cette question:

En observant le comportement de fatrace, je remarque quelque chose qui me préoccupe. Voici les premières lignes de sortie de la commande "fatrace | grep konsole"

konsole(4112): O /etc/passwd
konsole(4112): CO /etc/passwd
konsole(4112): C /etc/passwd
konsole(4112): O /etc/passwd
konsole(4112): C /etc/passwd
konsole(4112): O /etc/passwd
konsole(4112): C /etc/passwd
konsole(4112): O /etc/passwd
konsole(4112): C /etc/passwd
konsole(4112): O /etc/passwd
konsole(4112): C /etc/passwd
konsole(4112): O /etc/passwd
konsole(4112): C /etc/passwd
konsole(4112): O /etc/passwd
konsole(4112): C /etc/passwd
konsole(4112): O /etc/passwd
...

Le fait est que lsof | grep passwd montre que passwd n'est ouvert par aucun processus.

Alors une idée de ce qui se passe?

Vous pouvez lire le code source; en parlant de ... je l'ai fait pour vous; on dirait que ça vient du ProcessInfo.cppfichier. Il obtient les noms d'utilisateur. Non seulement cela /etc/passwdne vous préoccupe pas, tout le monde peut le lire. Vous pourriez cependant être inquiet s'il essayait de lire /etc/shadow.

En utilisant, stracevous pouvez voir ce qui konsolese passe.

$ strace -s 2000 -o konsole.log
...
...
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2655, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f316d8fc000
read(3, "root:x:0:0:root:/root:/bin/bash\nbin:x:1:1:bin:/bin:/sbin/nologin\ndaemon:x:2:2:daemon:/sbin:/sbin/nologin\nadm:x:3:4:adm:/var/adm:/sbin/nologin\nlp:x:4:7:lp:/var/spool/lpd:/sbin/nologin\nsync:x:5:0:sync:/sbin:/bin/sy
nc\nshutdown:x:6:0:shutdown:/sbin:/sbin/shutdown\nhalt:x:7:0:halt:/sbin:/sbin/halt\nmail:x:8:12:mail:/var/spool/mail:/sbin/nologin\noperator:x:11:0:operator:/root:/sbin/nologin\ngames:x:12:100:games:/usr/games:/sbin/nologin\nf
tp:x:14:50:FTP User:/var/ftp:/sbin/nologin\nnobody:x:99:99:Nobody:/:/sbin/nologin\ndbus:x:81:81:System message bus:/:/sbin/nologin\nsystemd-journal-gateway:x:191:191:Journal Gateway:/var/log/journal:/usr/sbin/nologin\npolkitd:
x:999:999:User for polkitd:/:/sbin/nologin\nusbmuxd:x:113:113:usbmuxd user:/:/sbin/nologin\ncolord:x:998:997:User for colord:/var/lib/colord:/sbin/nologin\nrpc:x:32:32:Rpcbind Daemon:/var/lib/rpcbind:/sbin/nologin\nqemu:x:107:
107:qemu user:/:/sbin/nologin\nrtkit:x:172:172:RealtimeKit:/proc:/sbin/nologin\ntss:x:59:59:Account used by the trousers package to sandbox the tcsd daemon:/dev/null:/sbin/nologin\nradvd:x:75:75:radvd user:/:/sbin/nologin\nabr
t:x:173:173::/etc/abrt:/sbin/nologin\nopenvpn:x:997:996:OpenVPN:/etc/openvpn:/sbin/nologin\nunbound:x:996:995:Unbound DNS resolver:/etc/unbound:/sbin/nologin\nsaslauth:x:995:76:\"Saslauthd user\":/run/saslauthd:/sbin/nologin\n
avahi:x:70:70:Avahi mDNS/DNS-SD Stack:/var/run/avahi-daemon:/sbin/nologin\navahi-autoipd:x:170:170:Avahi IPv4LL Stack:/var/lib/avahi-autoipd:/sbin/nologin\nrpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin\nnfsnobody
:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin\nnm-openconnect:x:994:994:NetworkManager user for OpenConnect:/:/sbin/nologin\nmailnull:x:47:47::/var/spool/mqueue:/sbin/nologin\nsmmsp:x:51:51::/var/spool/mqueue:/s
bin/nologin\nsshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin\ntcpdump:x:72:72::/:/sbin/nologin\npulse:x:993:993:PulseAudio System Daemon:/var/run/pulse:/sbin/nologin\ngdm:x:42:42::/var/lib/gdm:/sbin/nologin\
ngnome-initial-"..., 4096) = 2655
close(3)                                = 0
...

Konsole lit le contenu de /etc/passwdassez rapidement et vous ne le voyez pas avec lsof. Il s'agit d'un problème typique lorsqu'un fichier est ouvert, lu rapidement, puis fermé.

Dois-je m'inquiéter?

Soit dit en passant, cela ne pose aucun problème. Mon gnome-terminalfait la même chose. Le flux de choses peut être un peu déroutant, mais Konsole interroge le système pour une information. Dans ce cas, quelque chose comme le répertoire personnel de l'utilisateur.

Ainsi, le système appelle NSS (fichier de configuration de Name Service Switch):

open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3

Il y a une ligne dans ce fichier, en particulier cette ligne:

passwd:     files

Cette ligne indique à NSS où se trouve la "base de données" 'passwd'. Cette ligne indique à NSS que la ressource se trouve dans des fichiers. Le système ouvre alors le /etc/passwdfichier pour rechercher le répertoire personnel de l'utilisateur.

REMARQUE: creuser plus loin ce comportement semble être provoqué par Bash. Faire un stracede juste Bash montre la même chose.

$ strace -s 2000 -o bash.log bash

Lectures complémentaires

Si vous êtes vraiment intéressé par le fonctionnement de NSS, consultez les pages de manuel nsswitch.confet nss. NSS est modulaire et peut utiliser différentes technologies de backend pour ses "bases de données".

Par exemple:

       /etc/nsswitch.conf       NSS configuration file.
       /lib/libnss_compat.so.X  implements "compat" source.
       /lib/libnss_db.so.X      implements "db" source.
       /lib/libnss_dns.so.X     implements "dns" source.
       /lib/libnss_files.so.X   implements "files" source.
       /lib/libnss_hesiod.so.X  implements "hesiod" source.
       /lib/libnss_nis.so.X     implements "nis" source.
       /lib/libnss_nisplus.so.X implements "nisplus" source.

Pour la même raison, ls -llit / etc / passwd, ce sont les données qui associent les UID aux noms. Lors d' lsappels stat(2)sur un fichier, il obtient un UID numérique pour le propriétaire du fichier. Pour afficher cela comme un nom lisible par l'homme, il doit le rechercher au seul endroit qui possède ces associations /etc/passwd,. Par exemple, une première ligne typique /etc/passwdest

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

Quand ls -l /etc/hostsdoit produire la sortie

-rw-r--r-- 1 root root 222 Jan 14  2013 /etc/hosts

il doit traduire l'UID 0 en "root" car il appelle donc une routine de bibliothèque comme getpwuid qui lit /etc/passwdpour fournir la traduction. C'est une grande partie de la raison /etc/passwdexiste: pour fournir de telles traductions à des fins complètement banales.

La recherche de noms d'utilisateurs ne pose pas plus de problème de sécurité que d'appeler localtime, ce qui lsvous indique le "14 janvier 2013" pour l'heure de modification du fichier. Comme l'a noté slm , il n'y a aucune raison de garder le fichier ouvert, il est donc fermé dès que son contenu est lu.

À l'origine, le fichier /etc/passwdcontenait des mots de passe hachés. Les hachages de mot de passe ont été déplacés vers /etc/shadowlesquels les utilisateurs normaux ne peuvent pas lire car il s'agissait d'une faille de sécurité. Le nom est /etc/passwdresté le même mais contient maintenant xdans l'ancien champ de hachage de mot de passe qui n'est un hachage valide pour aucun mot de passe.