Поднять стык (interface) в Д8.
Доброго времени суток. Я не могу поднять eth0 в KVM, Дебиан-8: т.к. после установки, я удалил много пакетов, с ошибками, т.к. не было достаточно места на диске (маленький образ выбрал). /etc/udev/rules.d пусто. В /dev/net только tun присутствует. В /etc/network/interface имею: auto lo eth0 iface lo inet loopback iface eth0 inet dhcp allow-hotplug eth0 Пакет isc-dhcp-client установлен, и служба networking запущена. На ifup eth0 получаю: Ignoring unknown interface eth0=eth0. Как мне создать ус-во / поднять стык (interface)? Спасибо за помощь! С уважением, Ста. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140917134326.57bb9e0e@STNset
Re: Поднять стык (interface) в Д8.
On 17.09.2014 09:43, Ста Деюс wrote: Доброго времени суток. Я не могу поднять eth0 в KVM, Дебиан-8: т.к. после установки, я удалил много пакетов, с ошибками, т.к. не было достаточно места на диске (маленький образ выбрал). /etc/udev/rules.d пусто. В /dev/net только tun присутствует. В /etc/network/interface /etc/network/interfaces во множественном числе. имею: auto lo eth0 iface lo inet loopback iface eth0 inet dhcp allow-hotplug eth0 Пакет isc-dhcp-client установлен, и служба networking запущена. На ifup eth0 получаю: Ignoring unknown interface eth0=eth0. Как мне создать ус-во / поднять стык (interface)? Спасибо за помощь! -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54192fa7.4030...@kuklin.ru
Re: Поднять стык (interface) в Д8.
Доброго времени суток, Alex. Спасибо большое за ответ! Wed, 17 Sep 2014 09:52:23 +0300 вы писали: /etc/network/interface /etc/network/interfaces во множественном числе. Проблема решена, вопрос закрыт. :о) С уважением, Ста. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140917143217.249e77dd@STNset
Re: systemd, чтоб его
AC == Artem Chuprina r...@ran.pp.ru writes: Ivan Shmakov - debian-russian@lists.debian.org: AC Впрочем, если смотреть шире, то в данном случае это вообще AC замечательная и вся из себя прекрасная идея ленивых вычислений. AC Которая, кстати, давно частично реализована в юниксах в части AC сетевых взаимодействий (inetd). AC Но полезность inetd ограничена тем, что он, во-первых, не умеет AC действовать по схеме при первом запросе поднять сервис и оставить AC его работать (а это довольно часто нужно), а во-вторых, не умеет AC поднять зависимости. А в-третьих, тем, что он это умеет только для AC сети. IS Что примечательно, – inetd (почти уверен, — во всех его вариантах) IS умеет работать не занимая PID 1. Зачем сие потребовалось Systemd — IS совершенно не представляю. AC Тут скорее следует говорить о том, что inetd не выполняет функции AC init, поэтому не заменяет его, потому и не занимает PID 1. Верно. При этом, повторюсь, — запуск процессов — вне зависимости от поддержки зависимостей, Cgroups, и прочих Dbus — совершенно ортогонален выполнению функций init. Примеры — все варианты Inetd, Supervisor, а равно и упомянутый в [1] некий Circus. [1] http://blog.jorgenschaefer.de/2014/07/why-systemd.html AC А systemd - выполняет, вследствие чего заменяет (ибо нафига тогда AC еще и init?), поэтому совершенно естественно, что PID 1 достается AC именно ему. BTW, какие именно функции init (в смысле PID 1) берет на себя Systemd? «Усыновление осиротевших процессов» и запуск условного /etc/init.d/rcS при запуске системы? Так с этими задачами /уже/ справляется SysV init. Для чего потребовалась заново решать эту задачу «с нуля»? -- FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87y4tiaeq2@violet.siamics.net
Re: systemd, чтоб его
Eugene Berdnikov b...@protva.ru writes: On Tue, Sep 16, 2014 at 10:21:34PM +, Ivan Shmakov wrote: Eugene Berdnikov b...@protva.ru writes: Но быть сервисом, критичным для функционирования системы, без всякой защиты (от пейджинга, OOM-киллера, ошибочного сигнала и т. п.) просто глупо. […] Ядро юникса такую защиту init'у предоставляет, и это правильно. Я так подозреваю, — оно может и другим процессам такую защиту предоставлять (mlockall?), пусть даже и не по-умолчанию. Может, но mlockall это защита лишь от части источников риска, для защиты от сигналов в юниксе API нет. Что значит «защита от сигналов»? Ядро обрабатывает только два сигнала: SIGKILL и SIGSTOP; все остальное — процесс, в соответствии с собственными предпочтениями. Кроме того, на SIGSEGV оная «защита» не распространяется. Так что маленькая ошибка в коде Systemd чревата большим kernel panic. В отличие от Inetd или Supervisor. SIGSEGV не должен приводить напрямую к kernel panic. Действительно, SIGSEGV можно обработать. Но я не уверен, что это действительно разумно для PID 1 в общем, и реализовано в Systemd в частности. Так что по факту, — SIGSEGV для PID 1 приводит к завершению PID 1 и, следовательно, kernel panic. А насчёт монолитности и гранулярности здесь пробегали ссылки — авторы systemd утверждают, что их изделие поделено на множество мелких частей, общающихся как процессы с определённым интерфейсом, так что краха всей системы при ошибке в одном из бинарников быть не должно. Кроме того случая, когда ошибка происходит конкретно в коде, выполняемом как PID 1. Что, на мой взгляд, является хорошим поводом оставлять код PID 1 как можно более простым, — может быть, даже проще, чем существующий SysV init. Есть подозрение, что Systemd такого варианта не предлагает. -- FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87tx46ac1e@violet.siamics.net
Offtop: ИБП вендоров Liebert и Alpha Technologies (Pinnacle Plus Series)
День добрый. Кто-нибудь юзал ИБП этих вендоров? Хотелось бы услышать отзывы об использовании... -- WBR, Andrey N. Prokofiev Phone: +7-812-645-3616 ext. 240 -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54194b0c.7060...@korona-auto.com
Re: systemd, чтоб его
Ivan Shmakov - debian-russian@lists.debian.org @ Wed, 17 Sep 2014 07:27:49 +: AC Впрочем, если смотреть шире, то в данном случае это вообще AC замечательная и вся из себя прекрасная идея ленивых вычислений. AC Которая, кстати, давно частично реализована в юниксах в части AC сетевых взаимодействий (inetd). AC Но полезность inetd ограничена тем, что он, во-первых, не умеет AC действовать по схеме при первом запросе поднять сервис и оставить AC его работать (а это довольно часто нужно), а во-вторых, не умеет AC поднять зависимости. А в-третьих, тем, что он это умеет только для AC сети. IS Что примечательно, – inetd (почти уверен, — во всех его вариантах) IS умеет работать не занимая PID 1. Зачем сие потребовалось Systemd — IS совершенно не представляю. AC Тут скорее следует говорить о том, что inetd не выполняет функции AC init, поэтому не заменяет его, потому и не занимает PID 1. ISВерно. При этом, повторюсь, — запуск процессов — вне ISзависимости от поддержки зависимостей, Cgroups, и прочих Dbus — ISсовершенно ортогонален выполнению функций init. Примеры — все ISварианты Inetd, Supervisor, а равно и упомянутый в [1] некий ISCircus. Насчет ортогональности я бы попросил... Все-таки init выполняет функции корня дерева процессов - во-первых, бутстрап (запуск первых процессов), а во-вторых, сбор вымерших сиротинушек со всей системы и подметание за ними. Плюс он же, что вполне естественно ровно по причине PID 1 (т.е. заранее известно, кому именно слать сигнал) реагирует на общесистемные сигналы типа потери питания и запроса шатдауна. Хотя это уже, глядя на его man, переехало на использование /run/initctl (undocumented, судя по тому же man). Еще он отвечает за локальные логины в консоль, потому что в свое время больше некуда было засунуть запуск getty, ну, так это и осталось. IS [1] http://blog.jorgenschaefer.de/2014/07/why-systemd.html AC А systemd - выполняет, вследствие чего заменяет (ибо нафига тогда AC еще и init?), поэтому совершенно естественно, что PID 1 достается AC именно ему. ISBTW, какие именно функции init (в смысле PID 1) берет на себя ISSystemd? «Усыновление осиротевших процессов» и запуск условного IS/etc/init.d/rcS при запуске системы? Так с этими задачами /уже/ ISсправляется SysV init. Для чего потребовалась заново решать эту ISзадачу «с нуля»? Скажем так, и эти тоже. С SysV init у нас сейчас в системе N различных супервизоров и запускателей процессов для разных ситуаций - сам init, inetd, dbus-daemon, *dm, ну и вот супервизоры-велосипеды. У большинства из них система зависимостей либо кривая, как у нынешнего SysV init (не у самого init, а у /etc/rc, как я понимаю), либо вообще отсутствует. Сама по себе идея причесать этот разброд и аккуратно поделить на процессы, добавив ей ленивости - это очень хорошая идея. В частности, из SysV init откровенно следует выдрать работу с логинами и с power status (последняя там особенно крива), оставив только бутстрап (в смысле, запуск супервизора с нужными параметрами и фоллбэк на случай, если он сдох), запуск шатдауна (через пинок супервизора и фоллбэк на случай, если тот сдох) и сбор сиротинушек. То, что, по слухам (сам еще не проверял, врать не буду), реализация этой идеи в systemd кривая, не делает прямее нынешний SysV init и не портит саму идею. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87tx46r366@wizzle.ran.pp.ru
Re: systemd, чтоб его
Artem Chuprina - debian-russian@lists.debian.org @ Wed, 17 Sep 2014 13:45:21 +0400: AC Скажем так, и эти тоже. С SysV init у нас сейчас в системе N различных AC супервизоров и запускателей процессов для разных ситуаций - сам init, AC inetd, dbus-daemon, *dm, ну и вот супервизоры-велосипеды. Ах, да, кто-то уже упоминал automount и udev. Это туда же, где dbus-daemon. Мне сейчас приходится строить довольно сложную конфигурацию для автомагического доступа к флешкам - во-первых, udev, который обнюхивает флешку и делает симлинк в известном месте, а во-вторых, automount, который монтирует ее по запросу разыменования того симлинка и, главное, аккуратно отмонтирует вскоре после окончания ее использования. Она работает, но... AC У большинства из них система зависимостей либо кривая, как у нынешнего AC SysV init (не у самого init, а у /etc/rc, как я понимаю), либо вообще AC отсутствует. AC Сама по себе идея причесать этот разброд и аккуратно поделить на AC процессы, добавив ей ленивости - это очень хорошая идея. В частности, AC из SysV init откровенно следует выдрать работу с логинами и с power AC status (последняя там особенно крива), оставив только бутстрап (в AC смысле, запуск супервизора с нужными параметрами и фоллбэк на случай, AC если он сдох), запуск шатдауна (через пинок супервизора и фоллбэк на AC случай, если тот сдох) и сбор сиротинушек. То, что, по слухам (сам еще AC не проверял, врать не буду), реализация этой идеи в systemd кривая, не AC делает прямее нынешний SysV init и не портит саму идею. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ppeur1n3@wizzle.ran.pp.ru
Re: systemd, чтоб его
On 2014.09.17 at 08:25:49 +, Ivan Shmakov wrote: Что, на мой взгляд, является хорошим поводом оставлять код PID 1 как можно более простым, — может быть, даже проще, чем существующий SysV init. Есть подозрение, что Systemd такого варианта не предлагает. Я вообще туда иногда шелловский скрипт строчек из 20 ставлю. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140917110442.ga27...@wagner.pp.ru
Re: systemd, чтоб его
On 2014.09.17 at 13:45:21 +0400, Artem Chuprina wrote: У большинства из них система зависимостей либо кривая, как у нынешнего SysV init (не у самого init, а у /etc/rc, как я понимаю), либо вообще отсутствует. Нынешний SysV init это не более чем система соглашений о том, как писать шелловские скрипты, которые будет init запускать при переходе с ранлевела на ранлевел. Она полностью отдельна от самого init (который с тем же успехом будет запускать bsd-style rc-скрипты) и этим и хороша. Сама по себе идея причесать этот разброд и аккуратно поделить на процессы, добавив ей ленивости - это очень хорошая идея. В частности, Только идея вносить для этого изменения в код /sbin/init, не говоря уж о том, чтобы заменять его на другие процессы - однозначно плоха. Вызывайте из inittab хоть make, хоть prolog - это пожалуйста. из SysV init откровенно следует выдрать работу с логинами и с power Вот-вот. Следует выдрать. А не следует писать монстра, куда добавлять и то, и другое, и двадцать пятое. Но, surprise - sysV init с логинами и не работает. Единственное что он делает, это респавнит некоторые процессы по их завершению. А что это будут за процессы - getty (которая уже ближе к понятию работает с логинами - во всяком случае exec(/bin/login..) она делать умеет) X-сервер (который опять же с логинами нифига не работает) или еще какой-нибудь сетевой сервер - не важно X-сервер с респавном запускать кстати для X-терминалов, в которых логины обслуживаются удаленным *dm - вполне разумная идея. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140917111314.gb27...@wagner.pp.ru
Re: systemd, чтоб его
Victor Wagner - debian-russian@lists.debian.org @ Wed, 17 Sep 2014 15:13:14 +0400: У большинства из них система зависимостей либо кривая, как у нынешнего SysV init (не у самого init, а у /etc/rc, как я понимаю), либо вообще отсутствует. VW Нынешний SysV init это не более чем система соглашений о том, как VW писать шелловские скрипты, которые будет init запускать при переходе VW с ранлевела на ранлевел. Она полностью отдельна от самого init (который VW с тем же успехом будет запускать bsd-style rc-скрипты) и этим и хороша. Нет, это еще, во-первых, сам /sbin/init и /etc/inittab, а во-вторых, /etc/rc. В смысле, тот скрипт, который собственно и запускает те скрипты, про которые соглашение. Не говоря уже о том, что это соглашение в каждом дистрибутиве свое. Различается деталями, но дьявол именно в них. Сама по себе идея причесать этот разброд и аккуратно поделить на процессы, добавив ей ленивости - это очень хорошая идея. В частности, VW Только идея вносить для этого изменения в код /sbin/init, не говоря уж о VW том, чтобы заменять его на другие процессы - однозначно плоха. VW Вызывайте из inittab хоть make, хоть prolog - это пожалуйста. Глядя на man inittab и на man init, мне представляется, что SysV /sbin/init - это спагетти минимум из трех сортов макарон. Если в systemd их разделили на три бинарника (или более) - это хорошо. Если нет - плохо. Я так понял, глянув краем глаза, что там таки да, N различных бинарников. Может, и разделили. из SysV init откровенно следует выдрать работу с логинами и с power VW Вот-вот. Следует выдрать. А не следует писать монстра, куда добавлять и VW то, и другое, и двадцать пятое. Но, surprise - sysV init с логинами и VW не работает. VW Единственное что он делает, это респавнит некоторые процессы по их VW завершению. Вот это-то и выдрать. Поскольку это далеко не единственный action у него, и там макароны. Для минимального /sbin/init он умеет слишком много разного, а для нормального системного супервизора - слишком мало. VW А что это будут за процессы - getty (которая уже ближе к понятию VW работает с логинами - во всяком случае exec(/bin/login..) она VW делать умеет) X-сервер (который опять же с логинами нифига не VW работает) или еще какой-нибудь сетевой сервер - не важно VW X-сервер с респавном запускать кстати для X-терминалов, в которых логины VW обслуживаются удаленным *dm - вполне разумная идея. Начнем с того, что там остальная функциональность-то не нужна... Там действительно в качестве /sbin/init подойдет шелловский скрипт на 20 строк. Или даже сишный код на 40 :) -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87lhpiqvph@wizzle.ran.pp.ru
Re: systemd, чтоб его
On 2014.09.17 at 16:26:34 +0400, Artem Chuprina wrote: Если в systemd их разделили на три бинарника (или более) - это хорошо. Если нет - плохо. Я так понял, глянув краем глаза, что там таки да, N различных бинарников. Может, и разделили. В systemd слишком много бинарников. И xml-ные конфиги вместо шелловских скриптов. Вообще бы стоило поступить (вопрос в том, кто может на это решиться? Ну не Линус же) как Кнут. Который сказал делайте что хотите, но не называйте это TeX. Сказать. что вот этот ваш замечательный systemd конечно замечательный, но не называйте систему, где он есть GNU/Linux и, тем более unix. Пусть будет скажем Gnome System или Potterix. Типа вот есть же android, где вполне себе линуксовое ядро. Но никто не претендует на то что это linux или Unix. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140917130223.ga31...@wagner.pp.ru
Re: systemd, чтоб его
On Wednesday, September 17, 2014 5:02:23 PM MSK, Victor Wagner wrote: В systemd слишком много бинарников. И xml-ные конфиги вместо шелловских скриптов. В самом деле? Там INI-файлы, это проще и понятнее скриптов. Пусть будет скажем Gnome System или Potterix. Типа вот есть же android, где вполне себе линуксовое ядро. Но никто не претендует на то что это linux или Unix. Есть ещё Ubuntu, на её сайте нет ни слова про Linux :) -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/77b31d15-cef9-4dc5-9b00-06e5c7fe9...@lists.xtsubasa.org
Re: systemd, чтоб его
Ivan Shmakov i...@siamics.net writes: Dmitrii Kashin free...@freehck.ru writes: […] Почему же, минимум усилий на правку конфигов как раз приложили: -- /etc/apt/preferences.d/80systemd -- Package: systemd-sysv Pin: release a=stable Pin-Priority: -1 Package: systemd-sysv Pin: release a=testing Pin-Priority: -1 […] Почему бы не обойтись одним Pin: с c=main? Package: systemd-sysv Pin: release c=main Pin-Priority: -1 Ну... Я было думал пожаловаться, что не нашёл нормальной документации о том, что можно писать в поле Pin, но сейчас вот смотрю в apt_preferences и краснею потихоньку. Похоже, я просто не дочитал. Большое спасибо. pgpNuaAoK9KV1.pgp Description: PGP signature
[DONE] wml://security/2014/dsa-302{5,6}.wml
Cheers! Lev Lamberov --- english/security/2014/dsa-3025.wml 2014-09-16 19:10:43.0 +0200 +++ russian/security/2014/dsa-3025.wml 2014-09-17 11:11:44.141513828 +0200 @@ -1,28 +1,30 @@ -define-tag descriptionsecurity update/define-tag +#use wml::debian::translation-check translation=1.2 maintainer=Lev Lamberov +define-tag descriptionобновление безопасности/define-tag define-tag moreinfo -pIt was discovered that APT, the high level package manager, does not -properly invalidate unauthenticated data +pБыло обнаружено, что APT, высокоуровневый менеджер пакетов, неправильно +отбрасывает неаутентифицированные данные (a href=https://security-tracker.debian.org/tracker/CVE-2014-0488;\ -CVE-2014-0488/a), performs -incorrect verification of 304 replies +CVE-2014-0488/a), выполняет неправильную +проверку 304 ответов (a href=https://security-tracker.debian.org/tracker/CVE-2014-0487;\ -CVE-2014-0487/a), does not perform -the checksum check when the Acquire::GzipIndexes option is used +CVE-2014-0487/a), не выполняет +проверку контрольных сумм при использовании опции Acquire::GzipIndexes (a href=https://security-tracker.debian.org/tracker/CVE-2014-0489;\ -CVE-2014-0489/a) and does not properly perform validation for binary -packages downloaded by the codeapt-get download/code command +CVE-2014-0489/a) и неправильно выполняет проверку двоичных +пакетов, загруженных при помощи команды codeapt-get download/code (a href=https://security-tracker.debian.org/tracker/CVE-2014-0490;\ CVE-2014-0490/a)./p -pFor the stable distribution (wheezy), these problems have been fixed in -version 0.9.7.9+deb7u3./p +pВ стабильном выпуске (wheezy) эти проблемы были исправлены в +версии 0.9.7.9+deb7u3./p -pFor the unstable distribution (sid), these problems have been fixed in -version 1.0.9./p +pВ нестабильном выпуске (sid) эти проблемы были исправлены в +версии 1.0.9./p -pWe recommend that you upgrade your apt packages./p +pРекомендуется обновить пакеты apt./p /define-tag # do not modify the following line #include $(ENGLISHDIR)/security/2014/dsa-3025.data # $Id: dsa-3025.wml,v 1.2 2014/09/16 17:10:43 kaare Exp $ + --- english/security/2014/dsa-3026.wml 2014-09-16 21:06:05.0 +0200 +++ russian/security/2014/dsa-3026.wml 2014-09-17 11:18:42.493494917 +0200 @@ -1,51 +1,53 @@ -define-tag descriptionsecurity update/define-tag +#use wml::debian::translation-check translation=1.2 maintainer=Lev Lamberov +define-tag descriptionобновление безопасности/define-tag define-tag moreinfo -pAlban Crequy and Simon McVittie discovered several vulnerabilities in -the D-Bus message daemon./p +pОлбан Креку и Симон МакВитэ обнаружили несколько уязвимостей в +службе сообщений D-Bus./p ul lia href=https://security-tracker.debian.org/tracker/CVE-2014-3635;CVE-2014-3635/a -pOn 64-bit platforms, file descriptor passing could be abused by -local users to cause heap corruption in dbus-daemon, -leading to a crash, or potentially to arbitrary code execution./p/li +pНа 64-битных платформах передача файлового дескриптора может использоваться +локальными пользователями для повреждения содержимого динамической памяти dbus-daemon, +что приводит к аварийному завершению работы или потенциальному выполнению произвольного кода./p/li lia href=https://security-tracker.debian.org/tracker/CVE-2014-3636;CVE-2014-3636/a -pA denial-of-service vulnerability in dbus-daemon allowed local -attackers to prevent new connections to dbus-daemon, or disconnect -existing clients, by exhausting descriptor limits./p/li +pОтказ в обслуживании в dbus-daemon позволяет локальным +злоумышленникам предотвратить создание новых соединений с dbus-daemon, либо отсоединить +существующих клиентов путём использования дескрипторов свыше установленного предела./p/li lia href=https://security-tracker.debian.org/tracker/CVE-2014-3637;CVE-2014-3637/a -pMalicious local users could create D-Bus connections to -dbus-daemon which could not be terminated by killing the -participating processes, resulting in a denial-of-service -vulnerability./p/li +pЛокальные злоумышленники могут создать соединения D-Bus с +dbus-daemon, которые не могут быть завершены путём остановки +участвующих процессов, что приводит к отказу в +отслуживании./p/li lia href=https://security-tracker.debian.org/tracker/CVE-2014-3638;CVE-2014-3638/a -pdbus-daemon suffered from a denial-of-service vulnerability in the -code which tracks which messages expect a reply, allowing local -attackers to reduce the performance of dbus-daemon./p/li +pdbus-daemon содержит отказ в обслуживании в +коде, которые отслеживает то, какие сообщения ожидают ответа, что позволяет локальным +злоумышленникам снизить производительность dbus-daemon./p/li lia href=https://security-tracker.debian.org/tracker/CVE-2014-3639;CVE-2014-3639/a -pdbus-daemon did not properly reject malicious connections from -local
