Если переключиться на 12-ю консоль и нажать Scroll Lock, то через некоторое время postfix, pop3-сервер (наверяка, и все остальные сервисы, что активно пишут в syslog) замораживаются и перестают отвечать.
Вообще-то это DoS, которому достаточно unprivileged physical access.
И что вы предлагаете?
This is a kernel problem: sending to unix dgram socket blocks in syscall. This particular case workarounded in syslogd-1.4.1-alt18.
Это обсуждалось уже очень давно: http://www.uwsg.iu.edu/hypermail/linux/kernel/0010.2/1130.html From: Ulrich Drepper <> Date: Mon Oct 23 2000 - 14:16:33 EST Jesse Pollard <> writes: > It's not a bug, but a security feature. NO log to syslogd should be lost, > since it may be related to an attack. That's exactly the argument I'm always using to turn down change requests like this. If the syslog() function could drop an entry and not send it is easy enough for somebody who has something to hide to overflow syslog() and then do the whatever s/he does not want to be logged. From: David S. Miller <> Date: Mon Oct 23 2000 - 14:28:36 EST [...] SOCK_DGRAM over AF_UNIX is reliable, it's a local transport. With AF_UNIX the only real difference between SOCK_DGRAM and SOCK_STREAM is whether writes must be atomic. F.e. for the SOCK_DGRAM case if you try to perform a write() larger than the socket buffer size you'll get a EMSGSIZE return, whereas for the same example in the SOCK_STREAM case the kernel will chop up the message for you and send over the pieces seperately to the peer socket.
Здрасьте. Получается, что несекьюрная настройка в /etc/syslogd.conf при заданной наблюдаемой реальности -- это INVALID? Меня как администратора *не колеблет*, чья это бага -- хоть аппаратного обеспечения. Если это позволяет DoS из коробки -- значит, такой настройки НЕ должно быть до тех пор, пока не будет реализован способ, при котором она возможна. Здесь он до детского очевиден: раз у нас важна надежная доставка сообщений в лог (это который пишется/передается), а вывод на tty12 как бы ни разу не важен, поелику все равно неизбежно куски из него теряются вследствие особенностей линуксового консольного драйвера -- значит, между надежным и нужным и ненадежным и малонужным (хотя и удобным) отсеками надо поставить буфер, который и будет дропать по мере надобности. Перевешиваю опять на syslogd, в общем.
Кстати, это Master blocker.
INVALID здесь относилось к "kernel: sending to unix dgram socket blocks in syscall", повешенному на ядро. В http://www.opengroup.org/onlinepubs/007904975/functions/send.html нигде не написано, что вызов send() не должен блокироваться для случая SOCK_DGRAM - это определяется только состоянием флага O_NONBLOCK. Поэтому поведение ядра в данном случае вполне соответствует стандарту - "If space is not available at the sending socket to hold the message to be transmitted, and the socket file descriptor does not have O_NONBLOCK set, send() shall block until space is available." Т.е. исправлять здесь надо не ядро, а syslogd.
Это проблема дизайна syslog(3), которую уже слишком поздно решать. Оригинальная проблема с tty12 решена в -alt18, хотя я считаю, что правильнее было бы просто выключить tty в syslog.conf
Дима. Я не верю, что ты, исправивший столько кода и написавший столько не то что оберток, а вещей посложнее, видишь проблему с написанием дропающего буфера -- cat, который бросает полный буфер, если есть вход. Странно все это. PS: согласен, что тогда лучше выкинуть tty из syslog.conf.
Я пожалуй тоже добавлю свои пару слов: 1) IMHO не надо убирать логи с /dev/tty12, это удобно и многие пользователи, сисадмины к этому привыкли. 2) IMHO стоит сделать по умолчанию в syslogd /dev/console, но при этом добавив утилиту-репликатор всего из /dev/console в /dev/xconsole (например)... а уже из /dev/xconsole вываливать логи на tty12 (или это будет делать та самая прога, которая будет реплицировать с /dev/console на /dev/xconsole). 3) соответственно придется пропатчить немного некоторое небольшое количество утилит, умеющих работать с /dev/xconsole.
