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.

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".

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.
–
GillesApr 19 '14 at 22:49

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.