web-dev-qa-db-ja.com

ulimitsのロギングを構成するにはどうすればよいですか？

limits がヒットしたときに何かがログに記録されるのではないかと思っていました（ファイルを開くなど）。もしそうなら、これはどこに記録され、私は何を探すべきですか？ CentOS6を使用しています。

linuxlogscentosulimit
4
cat pants

audit を使用して、対応するシステムコール（syscall）の失敗をログに記録できますが、すべての超過がこのように現れるわけではありません。たとえば、 Henk Langeveld が指摘しているように、_RLIMIT_RTTIME_を超えると、カーネルはシグナルを送信します。

たとえば、 _RLIMIT_NOFILE_ 制限を考えてみましょう：

このプロセスで開くことができる最大ファイル記述子番号より1大きい値を指定します。この制限を超えようとすると（ open（2） 、pipe（2）、dup（2）など）、エラーEMFILEが発生します。 （歴史的に、この制限はBSDでは_RLIMIT_OFILE_と呼ばれていました。）

したがって、たとえばopensyscallを監視する必要があります。その manページ は言う：

戻り値

open()、openat()、およびcreat()は、新しいファイル記述子を返します。エラーが発生した場合は-1を返します（この場合、 errno 適切に設定されています）。

エラー

open()、openat()、およびcreat()は、次のエラーで失敗する可能性があります。

EMFILE-プロセスにはすでに最大数のファイルが開かれています。

これは、openで失敗するEMFILEシステムコールを監査する必要があることを意味します。マニュアルページでは、openが-1を返し、errnoをEMFILEに設定することを提案していますが、実際には、opensyscallが_-EMFILE_を返します。 glibc変換-1に変換し、errnoをEMFILEに設定します *。

これで問題が解決したので、監査ルールを追加しましょう。

_[root@h ~]# auditctl -a always,exit -F Arch=`uname -m` -S open \
                                    -F uid=ciupicri -F exit=-EMFILE -k "UL-SE"
_

制限をテストしてみましょう：

_[ciupicri@h ~]$ ulimit -n 10
[ciupicri@h ~]$ python -c 'from __future__ import print_function; f = [(print(i), open("/etc/passwd")) for i in range(10)]'
0
1
2
3
4
5
6
7
Traceback (most recent call last):
  File "<string>", line 1, in <module>
IOError: [Errno 24] Too many open files: '/etc/passwd'
_

そして、ログを確認してください。

_[root@h ~]# ausearch --start recent -k UL-SE
...
time->Wed Jun 25 21:27:37 2014
type=PATH msg=audit(1403720857.418:63): item=0 name="/etc/passwd" nametype=UNK
NOWN
type=CWD msg=audit(1403720857.418:63):  cwd="/home/ciupicri"
type=SYSCALL msg=audit(1403720857.418:63): Arch=40000003 syscall=5 success=no 
exit=-24 a0=8ed72e0 a1=8000 a2=1b6 a3=8f24d11 items=1 ppid=1110 pid=1139 auid=
5000 uid=5000 gid=5000 euid=5000 suid=5000 fsuid=5000 egid=5000 sgid=5000 fsgi
d=5000 tty=pts3 ses=2 comm="python" exe="/usr/bin/python" subj=unconfined_u:un
confined_r:unconfined_t:s0-s0:c0.c1023 key="UL-SE"
...
_

Red Hat Enterprise Linux 6の「セキュリティガイド」には、 「システム監査」 の章があり、この章で詳細を読むことができます。

* これを指摘してくれてありがとう fche 。

3
Cristian Ciupitu

これについては、カーネルソースを検査する必要があります。

例：

LinuxカーネルのCPUタイマー（ posix-cpu-timers.c ）は、ハード制限に達すると、問題のあるプロセスにSIGKILLを送信します。ソフト制限は、SIGXCPUを1秒に1回トリガーし、ウォッチドッグメッセージをトリガーします。

詳細については、他の制限や信号を検索できます。

1
Henk Langeveld