Bug 3968 - kernel: sending to unix dgram socket blocks in syscall
Summary: kernel: sending to unix dgram socket blocks in syscall
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: syslogd (show other bugs)
Version: unstable
Hardware: all Linux
: P2 blocker
Assignee: Alexey Gladkov
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks: 3459
  Show dependency tree
 
Reported: 2004-04-13 19:03 MSD by Sergey V Kovalyov
Modified: 2006-12-17 16:22 MSK (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sergey V Kovalyov 2004-04-13 19:03:52 MSD
Если переключиться на 12-ю консоль и нажать Scroll Lock, то через некоторое
время postfix, pop3-сервер (наверяка, и все остальные сервисы, что активно пишут
в syslog) замораживаются и перестают отвечать.
Comment 1 Michael Shigorin 2004-04-20 22:25:50 MSD
Вообще-то это DoS, которому достаточно unprivileged physical access.
Comment 2 Dmitry V. Levin 2004-04-21 21:35:12 MSD
И что вы предлагаете? 
Comment 3 Dmitry V. Levin 2004-04-23 22:26:53 MSD
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 Sergey Vlasov 2004-04-23 23:34:11 MSD
Это обсуждалось уже очень давно:
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 Michael Shigorin 2004-04-26 12:31:46 MSD
Здрасьте.  Получается, что несекьюрная настройка в /etc/syslogd.conf при
заданной наблюдаемой реальности -- это INVALID?

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

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

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

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

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

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