Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

In relation to this question:

While observing the behavior of fatrace, I notice something which concerns me. Here are the first few lines of output of the command "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
...

The thing is that lsof|grep passwd shows that passwd is not open by any process.

So any idea what is going on?

share|improve this question
    
Why would it be a security concern that Konsole reads from /etc/passwd? This file contains all the information about user accounts, including the home directory and shell. –  Gilles Apr 19 at 22:51

3 Answers 3

You can read the source code; speaking of... I did it for you; it looks like it's from the ProcessInfo.cpp file. It's getting the usernames. Not only that /etc/passwd isn't a concern for you, anyone can read it. You might be worried though if it was trying to read /etc/shadow.

share|improve this answer
    
I think the bigger questions are: Why isn't lsof registering it? Why doesn't konsole just read /etc/paswd once? Also why does konsole need a list of usernames? –  Mouse.The.Lucky.Dog Apr 19 at 3:21
2  
It's probably going by too fast; you should use strace to get the PIDs file descriptor for further investigation. You can also play around with using peekfd –  josten Apr 19 at 3:22

Using strace you can see what konsole is up to.

$ 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 is reading the contents of /etc/passwd in fairly quickly and you're just not seeing it with lsof. This is a typical issue when a file is opened, read quickly, and then closed.

Should I be concerned?

This, by the way, is of no concern. My gnome-terminal does the same thing. The flow of things can be a bit confusing but Konsole is querying the system for a piece of information. In this case something like the user's home directory.

So the system makes a call to NSS (Name Service Switch configuration file):

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

There's a line in this file, specifically this line:

passwd:     files

This line tells NSS where the "database" 'passwd' can be found. This line is telling NSS that the resource is located in files. So the system then opens up the /etc/passwd file to look for the user's home directory.

NOTE: Digging further this behavior seems to be caused by Bash. Doing an strace of just Bash shows the same thing.

$ strace -s 2000 -o bash.log bash

Further readings

If you're genuinely interested in how NSS works then consult the man pages nsswitch.conf and nss. NSS is modular and can use different backend technologies for its "databases".

For example:

       /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.
share|improve this answer
1  
It isn't /etc/nsswitch.conf that triggers the loading of /etc/passwd, rather the opposite. Konsole wants to obtain some information about user accounts, so it opens /etc/nsswitch.conf, which tells it (inside libc code, not inside code from the Konsole source) that the user accounts are in /etc/passwd. –  Gilles Apr 19 at 22:49
    
@Gilles - OK, I'll reword that part, thanks. –  slm Apr 19 at 22:50
    
@Gilles - updated. –  slm Apr 19 at 23:07

For the same reason ls -l reads /etc/passwd, it is the data that associates UIDs with names. When ls calls stat(2) on a file it gets a numeric UID for the owner of the file. In order to display that as a human readable name, it needs to look it up in the only place that has those associations, /etc/passwd. For example a typical first line in /etc/passwd is

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

When ls -l /etc/hosts needs to produce the output

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

it needs to translate the UID 0 into "root" for so it calls a library routine like getpwuid which reads /etc/passwd to provide the translation. That's a large part of the reason /etc/passwd exists: to provide such translations for completely mundane purposes.

Looking up user names presents no more of a security issue than calling localtime so that ls can tell you "Jan 14 2013" for the modification time of the file. As slm noted, there's no reason to keep the file open, so it is closed as soon as its contents are read.

The file /etc/passwd did originally contain hashed passwords in simpler times. The password hashes were moved to /etc/shadow which normal users cannot read because it was a security hole. The name /etc/passwd stayed the same but now contains x in the former password hash field which is not a valid hash for any password.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.