Bug 3968 - kernel: sending to unix dgram socket blocks in syscall
: kernel: sending to unix dgram socket blocks in syscall
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/syslogd)
: unstable
: all Linux
: P2 blocker
Assigned To:
:
:
:
:
: 3459
  Show dependency tree
 
Reported: 2004-04-13 19:03 by
Modified: 2006-12-17 16:22 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2004-04-13 19:03:52
Если переключиться на 12-ю консоль и нажать Scroll Lock, то через некоторое
время postfix, pop3-сервер (наверяка, и все остальные сервисы, что активно
пишут
в syslog) замораживаются и перестают отвечать.
------- Comment #1 From 2004-04-20 22:25:50 -------
Вообще-то это DoS, которому достаточно unprivileged physical access.
------- Comment #2 From 2004-04-21 21:35:12 -------
И что вы предлагаете? 
------- Comment #3 From 2004-04-23 22:26:53 -------
This is a kernel problem: 
sending to unix dgram socket blocks in syscall. 
 
This particular case workarounded in syslogd-1.4.1-alt18. 
 
------- Comment #4 From 2004-04-23 23:34:11 -------
Это обсуждалось уже очень давно:
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.
------- Comment #5 From 2004-04-26 12:31:46 -------
Здрасьте.  Получается, что несекьюрная настройка в /etc/syslogd.conf при
заданной наблюдаемой реальности -- это INVALID?

Меня как администратора *не колеблет*, чья это бага -- хоть аппаратного
обеспечения.  Если это позволяет DoS из коробки -- значит, такой настройки НЕ
должно быть до тех пор, пока не будет реализован способ, при котором она
возможна.

Здесь он до детского очевиден: раз у нас важна надежная доставка сообщений в
лог
(это который пишется/передается), а вывод на tty12 как бы ни разу не важен,
поелику все равно неизбежно куски из него теряются вследствие особенностей
линуксового консольного драйвера -- значит, между надежным и нужным и
ненадежным
и малонужным (хотя и удобным) отсеками надо поставить буфер, который и будет
дропать по мере надобности.

Перевешиваю опять на syslogd, в общем.
------- Comment #6 From 2004-04-26 12:46:21 -------
Кстати, это Master blocker.
------- Comment #7 From 2004-04-26 13:26:30 -------
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.
------- Comment #8 From 2004-04-26 15:16:06 -------
Это проблема дизайна syslog(3), которую уже слишком поздно решать.

Оригинальная проблема с tty12 решена в -alt18, хотя я считаю, что правильнее
было
бы просто выключить tty в syslog.conf
------- Comment #9 From 2004-04-26 16:13:09 -------
Дима.  Я не верю, что ты, исправивший столько кода и написавший столько не то
что оберток, а вещей посложнее, видишь проблему с написанием дропающего буфера
-- cat, который бросает полный буфер, если есть вход.  Странно все это.

PS: согласен, что тогда лучше выкинуть tty из syslog.conf.
------- Comment #10 From 2004-05-13 13:40:47 -------
Я пожалуй тоже добавлю свои пару слов:

1) IMHO не надо убирать логи с /dev/tty12, это удобно и многие пользователи,
сисадмины к этому привыкли.
2) IMHO стоит сделать по умолчанию в syslogd /dev/console, но при этом добавив
утилиту-репликатор всего из /dev/console в /dev/xconsole (например)... а уже из
/dev/xconsole вываливать логи на tty12 (или это будет делать та самая прога,
которая будет реплицировать с /dev/console на /dev/xconsole).
3) соответственно придется пропатчить немного некоторое небольшое количество
утилит, умеющих работать с /dev/xconsole.