web-dev-qa-db-ja.com

konsoleが/ etc / passwdを読み取るのはなぜですか？

この質問に関連して：

ファトレースの振る舞いを観察していると、気になることがあります。コマンド「fatrace | grepkonsole」の出力の最初の数行は次のとおりです。

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

重要なのは、lsof | grep passwdは、passwdがどのプロセスでも開かれていないことを示しているということです。

それで、何が起こっているのか考えはありますか？

securityuserskonsole
8
Mouse.The.Lucky.Dog

ソースコードを読むことができます。と言えば...私はあなたのためにそれをしました。 ProcessInfo.cppファイルからのもののようです。ユーザー名を取得しています。 /etc/passwdが気にならないだけでなく、誰でも読むことができます。 /etc/shadowを読み込もうとしていたのか心配かもしれません。

9
user26053

straceを使用すると、konsoleが何をしているのかを確認できます。

$ 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は/etc/passwdの内容をかなり速く読み取っていますが、lsofでは表示されていません。これは、ファイルを開いてすばやく読み取り、閉じた場合の一般的な問題です。

私は心配する必要がありますか？

ちなみに、これは問題ではありません。私のgnome-terminalも同じことをします。物事の流れは少し混乱する可能性がありますが、Konsoleはシステムに情報を照会しています。この場合、ユーザーのホームディレクトリのようなものです。

したがって、システムはNSS（Name Service Switch構成ファイル）を呼び出します。

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

このファイルには次の行があります。具体的には次の行です。

passwd:     files

この行は、「データベース」「passwd」がどこにあるかをNSSに通知します。この行は、リソースがファイル内にあることをNSSに通知しています。そのため、システムは/etc/passwdファイルを開いて、ユーザーのホームディレクトリを探します。

注：この動作をさらに掘り下げると、Bashが原因のようです。 Bashだけでstraceを実行しても、同じことがわかります。

$ strace -s 2000 -o bash.log bash

さらなる読み物

NSSの動作に本当に興味がある場合は、マニュアルページnsswitch.confおよびnssを参照してください。 NSSはモジュール式であり、「データベース」にさまざまなバックエンドテクノロジーを使用できます。

例えば：

       /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.
8
slm

同じ理由で、_ls -l_は/ etc/passwdを読み取ります。これは、UIDを名前に関連付けるデータです。 lsがファイルに対してstat(2)を呼び出すと、ファイルの所有者の数値UIDを取得します。それを人間が読める形式の名前として表示するには、それらの関連付けがある唯一の場所_/etc/passwd_で検索する必要があります。たとえば、_/etc/passwd_の典型的な最初の行は

_root:x:0:0:root:/root:/bin/bash
_

_ls -l /etc/hosts_が出力を生成する必要がある場合

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

uID 0を「root」に変換する必要があるため、 getpwuid のようなライブラリルーチンを呼び出します。このルーチンは_/etc/passwd_を読み取って変換を提供します。それが_/etc/passwd_が存在する理由の大部分です：完全にありふれた目的のためにそのような翻訳を提供するためです。

ユーザー名を検索しても、 localtime を呼び出すだけでセキュリティ上の問題が発生するため、lsはファイルの変更時刻について「2013年1月14日」を通知できます。 slm で説明したように、ファイルを開いたままにする理由はないため、内容が読み取られるとすぐに閉じられます。

ファイル_/etc/passwd_には、元々ハッシュ化されたパスワードが含まれていました。パスワードハッシュは_/etc/shadow_に移動されましたが、セキュリティホールであったため、通常のユーザーは読み取ることができません。名前_/etc/passwd_は同じままですが、以前のパスワードハッシュフィールドにxが含まれていますが、これはどのパスワードに対しても有効なハッシュではありません。

7
msw