В компоненте Polkit, используемом в дистрибутивах для организации выполнения непривилегированными пользователями действий, требующих повышенных прав доступа (например, монтирования USB-накопителя), выявлена уязвимость (CVE-2021-3560), позволяющая локальному пользователю получить права root в системе. Уязвимость устранена в версии Polkit 0.119...Подробнее: https://www.opennet.me/opennews/art.shtml?num=55269
Ошибка логическая но виновата, конечно же сишнка. Сейчас прибегут иксперды скажут святой раст прикладывать к коду для безопасности.
от логических ошибок ни один яп не защищает, все что делает хруст это верифицирует работу с памятью.
Всё, что делает растишка - переводит некоторые проверки на время компиляции.
именно некоторые, при этом куда меньше чем тот-же clang + clang-tidy + clazy
О, вот и растоманы тебя минусуют.
я минус за кланг поставил.
> я минус за кланг поставил.Любитель rust всех спасёт?
>> я минус за кланг поставил.
> Любитель rust всех спасёт?я раст не люблю, как и шланг
я за GCC
> я раст не люблю, как и шланг
> я за GCCНу тут я поддерживаю. Хоть и с анализом clang получше будет.
> все что делает хруст это верифицирует работу с памятьюнет не делает. или память короткая?
хруст валится на определении доступного объёма памяти и течёт (пример по первому код в лисе, по второму код в хрустоос)
О, и тут растоман как ты говоришь с короткой памятью. хехе, классика фанатиков
И делает это все также неудачно. Мнда...
> Ошибка логическая но виновата, конечно же сишнка. Сейчас прибегут иксперды скажут святой раст прикладывать к коду для безопасности.Rust на 105% безопасен, возьмите и приложите его к своим творениям, немедленно! Кто-то даже говорит, что хруст помог ему от логических ошибок потому что он настолько безопасен, что автор кода думает только о логике, а не выходах за пределы отведенному его процессу сегмента памяти и прочих бэкдорах.
Конкретно в этом месте Rust и правда мог помочь: результат сискола был бы обёрнут в Result, и неправильно интерпретировать его было бы намного сложнее.На языках семейства ML (к которым пусть и с натяжкой, но можно отнести Rust) совершать логические ошибки труднее. Конечно возможно. Но не так легко.
мда
Rust на 146% безопасен!
чорт, 4% не хватает до нормального языка. эх.неосиляторы
>Сейчас прибегут иксперды скажут святой раст прикладывать к коду для безопасности.Ассемблер спасёт отца демократии! Вот я что-то вообще не припомню чтобы, скажем, в той же Колибри находили какие-то уязвимости.
Еще бы колибри была кому-то нужна и где-то использовалась.
Принцип неуловимого Джо в действии.
Конечно, виновата. Переписывали бы на хрусте - нет кода, нет проблем с безопастностью!Причем в случае этой поделки для "какввенде" это самое лучшее решение.
В Rust не выйдет так просто проигнорировать ошибку, функция будет возвращать не bool и писать в строку юзера, а вернёт Result<User, Error>При этом Error так просто в User не превратить, а в случае ошибки User достать будет нельзя
там не игнорировали ошибку. Судя по новости "функция polkit_system_bus_name_get_creds_sync() возвращает значение TRUE вместо FALSE, несмотря на то, что не смогла сопоставить процесс с uid/pid и проверить запрошенные для процесса привилегии".Судя по коду и по сделанной правке - там вызвали два асинхронных вызова к dbus и стали ждать, пока они не заполнят значения pid и uid, или пока не случится ошибка. А вот дальше, если случилась ошибка и вышли из процесса ожидания, не смогли определить по какой причине завершили ожидание. Ну и вернули TRUE вместо FALSE. Т.е ошибку проанализировали, но всё-равно так получилось, что отправились на ветку, что всё хорошо (ну или точнее не отправились на ветку, что всё плохо).
Это называется "не обработали ошибку". Они не проанализировали ошибку. Проверка условия ((data.retrieved_uid && data.retrieved_pid) || data.caught_error) -- это не анализ ошибки. Это детект того, что вызовы завершились.Мне, кстати, интересно... Вот смотри, если первый завершившийся асинхронный вызов вернёт ошибку, то цикл вылетит из-за этой ошибки, так? А возвращаемое значение второго вызова так и останется необработанным? Так? И к чему это может привести в случае с дубасом? Глянь, data лежит на стеке, если сделать return после обработки первого вызова, то где-то там в недрах клиентского кода дубаса останется указатель на data, и дубас что-то запишет туда, как только появятся данные и будет сделан следующий вызов g_main_context_iteration. Или дубас гарантирует, что оба вызова будут обработаны в течение одного g_main_context_iteration?
> Это детект того, что вызовы завершились.тут я с Вами не соглашусь - тут и анализ завершения и анализ наличия ошибки (насколько я понимаю расчёт был на то, что retrieved_uid и retrieved_pid никогда, при нормальном завершении, не могут быть равными 0 - pid процесса и uid пользователя (хотя последний для пользователя root таки будет равным 0))
> Мне, кстати, интересно... Вот смотри, если первый завершившийся асинхронный вызов вернёт
> ошибку, то цикл вылетит из-за этой ошибки, так? А возвращаемое значение
> второго вызова так и останется необработанным? Так? И к чему это
> может привести в случае с дубасом? Глянь, data лежит на стеке,
> если сделать return после обработки первого вызова, то где-то там в
> недрах клиентского кода дубаса останется указатель на data, и дубас что-то
> запишет туда, как только появятся данные и будет сделан следующий вызов
> g_main_context_iteration. Или дубас гарантирует, что оба вызова будут обработаны в течение
> одного g_main_context_iteration?по g_main_context_iteration() ничего сказать не могу - не специалист по glib, а могу только предполагать (см ниже.).
По поводу данных - там выше есть функция on_retrieved_unix_uid_pid() которая является callback-ом и которой передаётся указатель на эту data. Судя по всему сам указатель data в недрах dbus-а используется только для того, чтобы передать его callback-у, который там всё что надо будет заполнит. g_main_context_iteration() вызывает по одному callback-у (делает какой-то single iteration судя по документации), а т.к. потом (при наличии ошибки или при завершении одного из callback-ов), прекращает свой цикл, то попортить стек ему не удастся - второй callback вызвать будет некому. Возможно второе значение сбросится при удалении контекста в g_main_context_pop_thread_default(). Думаю, что там не всё так плохо, как могло-бы показаться на первый взгляд.
> тут я с Вами не соглашусь - тут и анализ завершения и анализ наличия ошибкиой, да какого хрена разница. Если вернуться в начало, то вообще исходно разговор начался с того, что rust бы спас от этой проблемы. А то к чему мы пришли -- это спор о смыслах слов. Был программерский спор, стал лингвистический. То есть, мы залезли в оффтоп.
Возвращаясь же к исходному вопросу: я не знаю, спас бы раст от этой проблемы или нет. Покажите мне, как на rust'е это делать, и тогда можно будет судить. Тот API который есть просто нежизнеспособен с растом, потому как там два вызова выше, которые принимают data как &mut ссылку, и где-то там хранят две mut ссылки на неё. Это ноно, нини, никак нельзя. В смысле и в C не стоит так делать, а если всё же делаешь, то надо ОЧЕНЬ сильно подумать, и потратить не менее получаса на поиск граблей, на которые можно наступить при этом. Но в rust'е это сильнее нельзя, потому что без unsafe'а сделать не удастся, а с unsafe'ом оно конечно можно, в смысле это могут принять другие, но только ежели unsafety не пересекает границ модуля. Здесь он пересекает. То есть g_dbus_connection_call должен быть unsafe вызовом (это лишь _соглашение_ растоманов, но они всё же следят за ним когда читают или пишут код). Ну а если мы начинаем использовать unsafe API, то гарантии раста, как бэ, подвисают в воздухе.
> По поводу данных - там выше есть функция on_retrieved_unix_uid_pid()
Которая, судя по её коду, заточена под то, что она будет вызвана дважды. На каждый асинхронный вызов она вызывает g_connection_call_finish. И что-то пишет в data, вне зависимости от того, как там сыграют ветки if'ов: она просто в разные места data пишет, в зависимости от if'ов. Если между этими двумя вызовами коллбека произойдёт return в polkit_system_bus_name_get_creds_sync, то второй вызов будет писать в удалённый стековый фрейм.
edit:
> делает какой-то single iteration судя по документацииА, вот это похоже на правду. Надо полагать, что dangling указателя, всё же не возникает.
>> тут я с Вами не соглашусь - тут и анализ завершения и анализ наличия ошибки
> ой, да какого хрена разница. Если вернуться в начало, то вообще исходно
> разговор начался с того, что rust бы спас от этой проблемы.
> А то к чему мы пришли -- это спор о смыслах
> слов. Был программерский спор, стал лингвистический. То есть, мы залезли в
> оффтоп.безотносительно спора - ну как-бы о словах надо договариваться, чтобы не получилось, что мы говорим одно и тоже слово, но каждый под ним понимает что-то своё.
А так, скажем так, что у них получилось обработать ошибку, но не до конца.
>[оверквотинг удален]
> не стоит так делать, а если всё же делаешь, то надо
> ОЧЕНЬ сильно подумать, и потратить не менее получаса на поиск граблей,
> на которые можно наступить при этом. Но в rust'е это сильнее
> нельзя, потому что без unsafe'а сделать не удастся, а с unsafe'ом
> оно конечно можно, в смысле это могут принять другие, но только
> ежели unsafety не пересекает границ модуля. Здесь он пересекает. То есть
> g_dbus_connection_call должен быть unsafe вызовом (это лишь _соглашение_ растоманов,
> но они всё же следят за ним когда читают или пишут
> код). Ну а если мы начинаем использовать unsafe API, то гарантии
> раста, как бэ, подвисают в воздухе.про Rust я не могу ничего сказать. как это в нём можно сделать вообще, и как именно делать лучше в частности.
>[оверквотинг удален]
> Которая, судя по её коду, заточена под то, что она будет вызвана
> дважды. На каждый асинхронный вызов она вызывает g_connection_call_finish. И что-то пишет
> в data, вне зависимости от того, как там сыграют ветки if'ов:
> она просто в разные места data пишет, в зависимости от if'ов.
> Если между этими двумя вызовами коллбека произойдёт return в polkit_system_bus_name_get_creds_sync,
> то второй вызов будет писать в удалённый стековый фрейм.
> edit:
>> делает какой-то single iteration судя по документации
> А, вот это похоже на правду. Надо полагать, что dangling указателя, всё
> же не возникает.как по мне, код на C вполне себе элегантный, правда что так и не понятно - зачем они делают два вызова? неужели боятся, что по одному могут ответить гораздо медленнее, чем по второму, но не знают по какому? или то какое-то legacy осталось, типа давайте спросим так, а если нас не поняли, то тогда по другому.
> ну как-бы о словах надо договариваться, чтобы не получилось, что мы говорим одно и тоже слово, но каждый под ним понимает что-то своё.Есть способ проще -- попытаться обойтись без использования этого слова. Заменить везде слово определением этого слова. И вот теперь уже не нужно вдаваться в лингвистические споры о том, какое определение правильнее, можно разговаривать по сути дела.
Очередной высер растофанатика, в ошибке не разобрался но уже своё мнение высказал и раст в нем уже победил.Еще раз он не игнорировал ошибку, просто функция выдала тру вместо фолс.
Это не логическая ошибка.Необработка ошибок (их игнорирование). И да, язык спокойно и незаметно позволяет это сделать.
В нормальном языке программирования ты должен обязательно обработать результат функции, если он может содержать ошибочные значения. Иначе ошибка компиляции.
Или явно, сознательно, указать что не будешь обрабатывать и игнорируешь.
Так сделано в Zig, и вроде в Rust такз.
Для этого есть __attribute__ ((warn_unused_result)) и gcc -Wall -Werror
но погромисты, такие погромисты.
[[nodiscard]] добавили в стандарт С23. Так что можно и без вендор лока...
Никто ошибку не игнорировал протри глаза.
>Ошибка логическая но виновата, конечно же сишнка.[rusttroll]Ну разумеется. Надо было писать на Rust![/rusttroll]
>святой растКомпилятор которого использует LLVM, написанный на C++. И написанный на C линкер из MSVC под виндой, и LLD или LD/GOLD под юниксом.
Виноват не язык, виноват дизайн - столько сложностей на пустом месте просто обязаны содержать ошибки.
Вот да. Того, кто туда потащил ещё и js -- проектировать надо учить "по морде чайником, и самоваром, и паяльником". И то у бегемота шансы выше.
Михаил, может поумерите свой модераторский пыл уже?
Думаю, это всё же Вам следует открыть для себя ссылку "лог модерирования" (внизу справа под комментариями к полному тексту новости): http://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi?az=li...
тем не менее))
> тем не менее))ладно :)
Так в Polkit притащили уже давно - spydermonkey.
Шигорин об этом и говорит, по-моему. И ладно бы ещё просто захотелось писать программируемые рулесы вместо старого ini формата (или там xml был, не помню уже за двностью), но нахрена же было тащить кусок браузера в 300 мегабайт, будто прогрессивное человечество не придумало других языков, которые легко в сишный код встраиваются (луа? не, не слышали).
> кусок браузера в 300 мегабайт$ rpm -q --qf '%{size}\n' lib64mozjs78_78-78.9.0-1.x86_64
1403043614, а не 300
>> кусок браузера в 300 мегабайт
> $ rpm -q --qf '%{size}\n' lib64mozjs78_78-78.9.0-1.x86_64
> 14030436
> 14, а не 300У тебя #define в Си объявляет переменную и размер кучи ты прикинуть не можешь, потому для тебя существенна разница меж 14 и 300 метрами исполняемого файла, без учёта его зависимостей.
А речь была о том, что незачем тащить ненужные мегабайты, когда хватило бы 200-300 Кб, а то и 50.
https://www.linux.org.ru/forum/security/15600248?cid=15622030Уважаемому Потерингу необходимо было сделать:
1. Придумать формат правил контроля доступа
2. Написать компилятор этих правил.
А для этого надо талант, время и деньги...Потеринг не сделал ничего, взял Java Script и его компилятор от Mozilla. А вы это "оно" жуйте и глотайте.
Миша, а когда, всеми любимый ALT Linux избавится от systemd, dbus, polkitd+JS?
Коль скоро C-шечка даёт свободу делать дизайн API плохим, он и дальше будет в среднем не очень.
Коль в срасту подпускают вебмакак. Они так и продолжат делать дизайн плохим. И язык им прям совсем никак не помешает это сделать.
> В компоненте, используемом для организации выполнения непривилегированными пользователями действий, требующих повышенных прав доступа, выявлена уязвимость, позволяющая локальному пользователю получить права root в системеНу кто бы мог подумать
Все десктоперские метастазы, которые породила Шляпа за прошедшие четверть века, заведомо небезопасны и принципиально не могут быть безопасными. Но мышки продолжают жевать этот горький десктоперский кактус и нахваливать, а не пользоваться традиционными консольными средствами с умом и пониманием.
и шрифт liberation тоже не безопасный?
Кстати, полкит - продукт редхата?
fd.o — продукт Редхата. Всё, что выходит из этой выгребной ямы и её окрестностей, включая системду — продукты Шляпы. А сама Шляпа с конца девяностных на довольствии у Межделмаша. Но вы, конечно, продолжайте верить в свободу и сообщество.
> fd.o — продукт Редхата. Всё, что выходит из этой выгребной ямы и её
> окрестностей, включая системду — продукты Шляпы. А сама Шляпа с конца девяностных
> на довольствии у Межделмаша. Но вы, конечно, продолжайте верить в свободу
> и сообщество.systemd кстати к fd.o не относиться, она просто редхатом разрабатывается (хотя Пёттеринг её создал до того как стал в редхате работать)
а так полкит вещь на мой взгляд очень дурацкая, хотя полезные применения имеет. Но зачем там js
надо будет попытаться её выкинуть из мое ОС
Не важно, во скольких коробках лежат редхатовские бирюльки, хозяин один и тот же.
Усложнения, усложнения не меняются.
А способа например просто записать в файл от рута в программе не от рута так и нет. Вообще привелегии "всё или ничего" это плохо.
Текстовому редактору например достаточно спросить разрешение на запись одного файла при попытке это сделать при сохранении... И не перезапускаться даже.
> Текстовому редактору например достаточно спросить разрешение на запись одного файла при
> попытке это сделать при сохранении... И не перезапускаться даже.Необходимо, что бы подобное разрешение запрашивала система. Получается UAC. При этом в сеансе Иксов такой запрос как раз будет обходим.
>Вообще привелегии "всё или ничего" это плохо.Привилегии "частично" реализуются Linux Capabilities.
образуя дыру, угу. Которой бы не было, если бы юникс-программа работала как юникс-программа.Нет, конечно же лет через пятьдесят все поперепишут на хруст и научатся сбрасывать излишние капабилити. (Нет. Но простой и внятно работающий софт изведут окончательно, точно.)
Как будто, в прграммах c suid'ом дыр не бывает. Поэтому capabilities и замутили.
Это юникс, чувак.
Если кому-то нужна была винда - надо было просто не выпендриваться и ставить винду.А вы налепили костылей и подпорочек.
> Текстовому редактору например достаточно спросить разрешение
текстовому редактору чтобы было достаточно "спросить" - нужно уже иметь эту возможнось. Получаем текстовый редактор, имеющий возможность делать ВСЁ. И прикрытую фиговым листиком "спросить".
Вот тебе и результаты, собственно.
> Это юникс, чувак.
> Если кому-то нужна была винда - надо было просто не выпендриваться и
> ставить винду.
> А вы налепили костылей и подпорочек.
>> Текстовому редактору например достаточно спросить разрешение
> текстовому редактору чтобы было достаточно "спросить" - нужно уже иметь эту возможнось.
> Получаем текстовый редактор, имеющий возможность делать ВСЁ. И прикрытую фиговым листиком
> "спросить".
> Вот тебе и результаты, собственно.Ну вся суть, что он не должен спрашивать, он должен просто записывать файл, как обычно.
В принципе диалог сохранения может быть отдельной программой с отдельными правами, а без вызова этой программы текстовый редактор не мог бы записать файл вообще никак. Нет вызова "сохранить файл", вызов программы сохранения это единственный легитимный способ и это и есть api сохранения файла. И аргументы командной строки связаны с бинарным интерфейсом.
Опять что-то ещё более страшное горожу? Хочу победить сложность и неадекватность, но придумываю свою сложность и неадекватность? Эх. Всё хорошо, пока системы поддерживают простыми, но потом начинается.
пусть нейросеть решает (или спор ИИ): запаха нет, плюсы на опеннет, вовремя апгрейдил - кредит доверия на запись в /etc.
> пусть нейросеть решает (или спор ИИ): запаха нет, плюсы на опеннет, вовремя
> апгрейдил - кредит доверия на запись в /etc.Не верю в непонятность слов.
> А способа например просто записать в файл от рута в программе не от рута так и нет.
>> В компоненте Polkit, используемом в дистрибутивах для организации выполнения непривилегированными пользователями действий, требующих повышенных прав доступа найдена уязвимость, позволяющая повысить свои привилегии в системеЧто? Корова купленная для молока дала молоко?
Ну просто поооолный пэээ...
Сколько можно-то?
Так polkit же и нужен для получения прав рута.Получается, программа просто делает свою работу.
Он как раз нужен, чтобы права рута не давать, а одобрить определённое действие из ограниченного набора, которое для пользователя сделает уже привилегированная программа.
> Он как раз нужен, чтобы права рута не давать, а одобрить определённое
> действие из ограниченного набора, которое для пользователя сделает уже привилегированная
> программа.Почему нельзя просто запускать привелегированный скрипт без возможности изменить его?
>Почему нельзя просто запускать привелегированный скрипт без возможности изменить его?1. У такого решения меньше гибкости.
2. Если предполагается много разных действий, понадобится либо несколько привилегированных скриптов, либо передавать туда аргументы, что в контексте интерпретируемых языков идея рискованная.
3. В policykit можно, например, для определённых действий затребовать у юзера авторизоваться как пользователь, а не обязательно как администратор.
4. Можно для разных действий установить разные правила хранения авторизаций при их повторном запросе.В общем, см. тут: https://www.freedesktop.org/software/polkit/docs/latest/polk...
Всегда удивляет нечистоплотность программистов в критичных програмах. Для чего функции что-то возвращают? Чтобы в пустоту исчезло?
Всю жизнь твердили:1. проверить данные
2. вызвать функцию
3. проверить результат
if (pData)
{
if (SomeProcessing(pData) == SUCCESS)
WeHaveAWinner();
}
> if (SomeProcessing(pData) == SUCCESS)Главное, чтобы это был не PHP...
Ну это же очевидно, надо просто вывести идеальных генно-модифицированных программистов, которые будут писать код без ошибок. Почему до сих пор не сделали?
Палишься, вендузятник, ой как палишься.
А зачем тогда жаловаться, что, например, Pascal и D проверяют границы массивов автоматически?
А кто жалуется? Я просто на них не пишу ) Ну, и толку в проде, что они проверяют? Разве что, контролируемый крэш, что полезно при отладке. Логика алгоритма всё равно зависит от того, как выход за границы будет обработан.
А если логика написана так что выход за границы массива при некоторых условиях оказался не обработан а должен бы был ? Пускай уж лучше крэшится чем молча за границу выйдет и хрен пойми что натворит.
С разморозкой. C++ тоже контролирует
Так, здесь по подробней. Специально проверял array<>, выходит за границы. Или я не то использую, чтоб контролируемо было?
Вы не показываете код, но просите угадать.The member function at() provides bounds-checked access to container elements. at() throws out_of_range if n >= a.size().
Спасибо. Я объект класса array индексировал [].
Специально предоставлено оба варианта, т.к. operator[] иногда чуть быстрее.
> Так, здесь по подробней. Специально проверял array<>, выходит за границы. Или я
> не то использую, чтоб контролируемо было?.at()
Крамольные вещи пишите... Если все программисты будут так писать, то даже сектанты раста начнут понимать, что он не нужен.
Кто в курсе, зачем Polkit'у зависимость от Spydermonkey?
> Кто в курсе, зачем Polkit'у зависимость от Spydermonkey?https://www.freedesktop.org/software/polkit/docs/latest/polk...
> Rules files are written in the JavaScript programming language and interface with polkitd through the global polkit object (of type Polkit).
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.accounts.user-administration" &&
subject.isInGroup("admin")) {
return polkit.Result.YES;
}
});
Я так понимаю, они правила на нём пишут
https://cgit.freedesktop.org/polkit/tree/src/polkitbackend/5...
Мда, ещё одна бомба замедленного действия. А аналога Polkit не существует?
аналог и не нужен. штатных средств системы достаточно
уж сколько я не люблю раст, а он бы тут не помог бы. потому что раст - гораздо сложнее чем си, а мы уже знаем, что усложнение языка - плохо влияет на головы любителей раста.по-этому, как любитель раста, авторитетно заявляю, что тут больше подошёл бы замечательный язык D (Ди - пря мо, как "леди Ди").
Лучше не заявляй. Здесь проблема в ДНК вендузятников. Это им по каждому чиху сервис нужен. Потому что не в состоянии осилить маны.Штатные средства системы со всем этим как справлялись так и справлются просто на ура. Это поделье вообще не нужно.
Не пользовал не пользую и не собираюсь пользовать. Штатные средства системы прекрасно справлялись со всем и без этого поделия набежавших вендузятников
Но от Polkit Кеды зависят. От Кедов отказываться не предлагать. Или их таки можно отвязать?
> Но от Polkit Кеды зависят. От Кедов отказываться не предлагать. Или их
> таки можно отвязать?если собирать из исхов то наверно да. А если нет - то нельзя т.к. полкит это впервую очередь либа и если с ней что то слинкованно -только пересборка
ну и мб там только 1-2 не очень важных компонента зависят - тогда да
> polkit_system_bus_name_get_creds_sync()Чего?
А ну да, вендузятники
we_are_windows_stupid_programmers_we_do_knows_nothin_but_we_want_to_be_cool_linux_programmers_rust_forever_hohoho_we_are_idiots(true)
>> polkit_system_bus_name_get_creds_sync()
> А ну да, вендузятники
> we_are_windows_stupid_programmers_we_do_knows_nothin_but_we_want_to_be_cool_linux_programmers_rust_forever_hohoho_we_are_idiots(true)ну, у "вендузятников" был-бы CamelCase:
WeAreWindowsStupidProgrammersWeDoKnowsNothinButWeWantToBeCoolLinuxProgrammersRustForeverHohohoWeAreIdiots(true).
точняк
Всяко лучше чем __с2_to_f()
Этот дырявый линукс...
Я каких пор polkit считается куском ядра?
С тех пор как системд
системд не зависит и не требует полкит и частью ядра не являетьсяи полкит от системд тоже не зависит
линукс меньше системд чем полкит.
> линукс меньше системд чем полкит.всмысле?
можно заменить системд на линуксе, но нельзя полкит.
> можно заменить системд на линуксе, но нельзя полкит.но можно от него избавиться
угу, и ничего не будет работать потому что альтернативы какой-либо не существует (на линуксе так точно).
> угу, и ничего не будет работать потому что альтернативы какой-либо не существует
> (на линуксе так точно).что не будет работать ?
полкит ничего важного не делает, нужен только чтоб хомячки могли без рута интернет настроить и монтировать файловые системы в файл менеджере не вводя пароль
этого мало? программы для работы с дисками от него зависят, да и утомительно каждый раз втыкая флешку вводить пароли
> этого мало? программы для работы с дисками от него зависят, да и
> утомительно каждый раз втыкая флешку вводить паролиgvfs от полкита не зависит, думаю что он всегда под рутом работает. Какие программы? только udisks
поблема только в 2-3 прогах требующих полкит в обязательном порядке
мимо, gvfs без полкита и udisks работать не будет. сам по себе gvfs ещё в тысячу раз хуже всех китов вместе взятых. в частности, он тянет avahi. успехов удалить udisks, кстати.
> мимо, gvfs без полкита и udisks работать не будет. сам по себе
> gvfs ещё в тысячу раз хуже всех китов вместе взятых. в
> частности, он тянет avahi. успехов удалить udisks, кстати.https://www.linuxfromscratch.org/blfs/view/systemd/gnome/gvf...
Requireddbus-1.12.20, GLib-2.68.2, libusb-1.0.24, libsecret-0.20.4 and libsoup-2.72.0
авахи это уже совершенно необязательная зависимость которую использует ваш дистр (дистростроители просто обожают пихать в зависимости весь опциональный мусор)с удискс сложности, гном его требует. но можно думаю исхи udisk чуть поправить и все норм будет
и удалят мне ни чего не надо, я предпочитаю не устанавливать
не устанавливать никакие de и никакой софт, только пердолиться со всем? ну, это, конечно, вариант, но есть вещи по-интереснее и можно потратить время полезнее. в частности, до сих пор нет очень многих вещей, даже аудиоплеера для линукса никто не написал до сих пор (как и вообще опенсорсного на самом деле).
> не устанавливать никакие de и никакой софт, только пердолиться со всем? ну,
> это, конечно, вариант, но есть вещи по-интереснее и можно потратить время
> полезнее. в частности, до сих пор нет очень многих вещей, даже
> аудиоплеера для линукса никто не написал до сих пор (как и
> вообще опенсорсного на самом деле).что мешает устанавливать de и софт
и помойму вполне себе можно любой аудио файл проиграть пользуясь только свободными программами
но ведь плеер это далеко не только воспроизведение, а так да. если устанавливать de или софт, те попросят какой-нибудь udisks с libsoup для своей работы и без них будут работать как минимум неполноценно, а часто и с ошибками, а часто и не будут работать вовсе.
> но ведь плеер это далеко не только воспроизведение, а так да. если
> устанавливать de или софт, те попросят какой-нибудь udisks с libsoup для
> своей работы и без них будут работать как минимум неполноценно, а
> часто и с ошибками, а часто и не будут работать вовсе.они просто не соберутся, если нет зависимости. но ПО которое требует полкит не много, можно и чуть чуть поправить исхи
с гномом сложно и увы я использую его, а не xfce (у которого зависимотей очень мало)
А вообще я от полкита не пытался избавиться, только теоритечески об этом рассуждаю. Но могу и попробовать
P. S. я если что использую лфс в качестве основной системы
это будет gvfs который только для бэкдора, и как максимум сливает телеметрию и больше ничего не делает? судя по libsoup
> это будет gvfs который только для бэкдора, и как максимум сливает телеметрию
> и больше ничего не делает? судя по libsoupкакая телеметрия? можно можно также и не обязательные зависимости использовать. Да и без них gvfs вполне работоспособен. но собирать его с avahi вовсе необязательно. У него еще и apache - опциональная зависимость.
я просто говорю что зависимости у дистров и зависимости реальные - разные вещи
не так. полкит больше линукс, чем системд.
> не так. полкит больше линукс, чем системд.линукс - https://www.kernel.org/
а демон на жс не как не заменяет его
линукс это общее название операционных систем на базе ядра линукс, обычно под этим названием подразумевается гнулинукс т.н. "десктоп".
> линукс это общее название операционных систем на базе ядра линукс, обычно под
> этим названием подразумевается гнулинукс т.н. "десктоп".если вы про ОС как набор компонентов то все примерно тоже самое - полкит его не заменяет и только может быть туда включен (а может и не быть)
>С тех пор как системдТьфу-тьфу-тьфу, это овно ещё не ядре.
Шо опять не на расте?