Вообще-то это 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.