LINUX.ORG.RU
Форум — Development  

И снова Лёня на связи! Systemd и безопасность!

 , , , ,


0

3

Пацаны предлагают сократить и переделать зависимости systemd и внешних библиотек. Инициатива хорошая, да реализация :facepalm:!

https://github.com/systemd/systemd/issues/32028#issuecomment-2031366922

https://www.opennet.ru/opennews/art.shtml?num=60912

Если кратко, Лёня категоричен - systemd должно быть монолитным.

Sorry, but no. Splitting this up makes a mess, since it makes sharing internal code much harder. You either have to make all our internal helpers public symbols (which means namespacing issues, ABI stability and all that fuck), or you «statically» compile the shared libraries, i.e. you duplicate the internal helpers in each split up library, exploding the size on disk. Which is also terrible.

А как бы Вы решали существующую проблему?
Какие мысли?
Если такая реакция, что получается? Основная атака была как раз на systemd дистрибутивы?



Последнее исправление: masterOf (всего исправлений: 1)

 ← 1 2 3 →

ехал жирный поезд пассажирный…

системд настолько жирный, что ему трудно дышать..

перепишите его уже с нуля…

в исходниках огромный объем непонятно чего, но эти люди еще на иксы что-то тянут…

anonymous
()

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

все имхо.

sunjob ★★★★
()
Последнее исправление: sunjob (всего исправлений: 1)

Я думаю, что Поттеринг мужик умный и лучше остальных знает как надо. Я бы его послушал, а не выпендривался со своим мнением. Он там не то, что синьор, а бог-архитектор. Как сказал, так и будет. И нечего тут разглагольствовать.

vbr ★★★
()

Если у systemd убрать зависимости, либо компилировать статически как предлагают, то его не будет притягивать по зависимостям, соответсвенно он никому не будет нужен и про него все быстро забудут. Что недопустимо для Поттеринга, соотвественно.

vbcnthfkmnth123 ★★★★★
()

Именно поэтому runit, OpenRC и прочие до сих пор живы, BSD системы тоже. Слишком уж жирная системда с огромной площадью атаки.

anonymous
()
Ответ на: комментарий от hateyoufeel

к чему это?! микроядро с модулями/сервисами? по моему нет?! я ошибаюсь?

пока хватает одного из «старичков», кот. наиболее понятен и близок (на линухе, кроме всего прочего др...ва, простите, нужно еще просто «работать» ... вчера, сегодня, завтра)

ну и я отвечал, весьма отвлеченно. топик об систем-Не?!

спасибо

sunjob ★★★★
()
Последнее исправление: sunjob (всего исправлений: 3)

А что ж вы самый нажор не упомянули - его еще и ELF не устраивает.

Ему говорят - libsystemd слишком жирная
Он - использует dlopen на некоторые библиотеки
Ему - ну теперь не видно зависимости и трудно отлаживать
Он - значит надо в ELF добавлять секции со списком динамических зависимостей!

PPP328 ★★★★★
()
Ответ на: комментарий от wandrien

В libsystemd предоставляется доступ к 12 базовым API (sd-bus, sd-daemon, sd-device, sd-event, sd-hwdb, sd-id128, sd-journal, sd-login, sd-netlink, sd-network, sd-path и sd-resolve) и возникает ситуация, когда приложение, например, использующее libsystemd только ради вызова функции sd_notify для информирования systemd об изменении состояния или sd_journal для записи данных в лог, связывается со всеми остальными библиотеками и обработчиками API. В качестве выхода предлагается разделить libsystemd на несколько отдельных библиотек, отвечающих за отдельные API, что позволит подгружать сторонние зависимости только там, где они необходимы.

В самой новости

PPP328 ★★★★★
()
Ответ на: комментарий от wandrien

Это хорошая идея.

Это говорит о том, что вы не писали модульные программы, когда нельзя заранее сказать, какой модуль вы будете использовать, а какого даже не существует на этой платформе. Про то что имя модуля может приехать снаружи вообще молчу.

PPP328 ★★★★★
()

I have the suspicion that the folks arguing for the split up never tried of maintain a set of somewhat related C libraries with 100% API compat over a decade, themselves. If they just tried, they’d soon realize what a mess that will become for them.

MaZy ★★★★★
()
Ответ на: комментарий от wandrien

Я что то не понял, названия процедур и так указываются, что еще нужно? Указать откуда именно они прилетают? Это сломаются хаки с LD_PRELOAD. Это пусть в ПМ лучше указывается.

MOPKOBKA ★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)

А как бы Вы решали существующую проблему?

Признал бы что текущий дизайн - шлак и передизайнил, чтобы разделение на части не приводило к страданиям.

ya-betmen ★★★★★
()

А как бы Вы решали существующую проблему?

Встав в горделивую позу шизофреника, я бы сказал, что это опенсорц, а в опенсорце вам ни-кто ни-че-го не дол-жен. И если вы не согласны с одним из лучших софтваре-инженегров современности, можете форкнуть линупс и внести изменения по вкусу. Принципиальная возможность у вас есть! :)

anonymous
()
Ответ на: комментарий от Beewek

Да от федоры на кедах все равно никакой пользы, чисто эстетическая разве что. С гномеров похихикать. Кривоватый коммунальный полигон с кедами от коммерсантов уже есть, называется «опенсусе», зачем еще один?

thesis ★★★★★
()
Ответ на: комментарий от thesis

Да от федоры на кедах все равно никакой пользы, чисто эстетическая разве что. С гномеров похихикать.

Ну и я об этом - все эти инициативы просто ради похихикать, без шансов на реализацию.

Beewek ★★
()
Ответ на: комментарий от PPP328

надо в ELF добавлять секции со списком динамических зависимостей!

И это было бы очень хорошо, если бы эта информация действительно в ELF’ах сохранялась. Подобное очень сильно бы упростило деплой приложений. Какой-нибудь Qt тянет ~30 явных зависимостей (видных в ldd) и ~15 сущностей динамических зависимостей, которые хрен нормально все вычленишь и соберёшь.

Но так как Linux сегодня это не про удобство использования и деплоя приложений, то вот вам AppImage со сломанными стилями в приложениях (как раз потому что они динамически через dlopen подгружаются).

EXL ★★★★★
()
Ответ на: комментарий от EXL

то вот вам AppImage со сломанными стилями в приложениях (как раз потому что они динамически через dlopen подгружаются)

А можно подробнее, как они там подгружаются? И что за механизм отвечает за убожество стилей в онтопике? Как это всё гуглится?

damix9 ★★★
()
Ответ на: комментарий от damix9

А можно подробнее, как они там подгружаются?

Через механизмы Qt вроде QPA, которые в конечном итоге упираются в dlopen() и пр.

Вот это всё барахло

plugins/
├── audio
│   ├── libqtaudio_alsa.so
│   └── libqtmedia_pulse.so
├── bearer
│   ├── libqconnmanbearer.so
│   ├── libqgenericbearer.so
│   └── libqnmbearer.so
├── designer
│   ├── libpyqt5.so
│   ├── libqquickwidget.so
│   └── libqwebview.so
├── egldeviceintegrations
│   ├── libqeglfs-emu-integration.so
│   ├── libqeglfs-kms-egldevice-integration.so
│   ├── libqeglfs-kms-integration.so
│   └── libqeglfs-x11-integration.so
├── generic
│   ├── libqevdevkeyboardplugin.so
│   ├── libqevdevmouseplugin.so
│   ├── libqevdevtabletplugin.so
│   ├── libqevdevtouchplugin.so
│   ├── libqlibinputplugin.so
│   └── libqtuiotouchplugin.so
├── iconengines
│   └── libqsvgicon.so
├── imageformats
│   ├── libqgif.so
│   ├── libqico.so
│   ├── libqjpeg.so
│   └── libqsvg.so
├── mediaservice
│   ├── libgstaudiodecoder.so
│   ├── libgstcamerabin.so
│   ├── libgstmediacapture.so
│   └── libgstmediaplayer.so
├── platforminputcontexts
│   ├── libcomposeplatforminputcontextplugin.so
│   └── libibusplatforminputcontextplugin.so
├── platforms
│   ├── libqeglfs.so
│   ├── libqlinuxfb.so
│   ├── libqminimalegl.so
│   ├── libqminimal.so
│   ├── libqoffscreen.so
│   ├── libqvnc.so
│   ├── libqwayland-egl.so
│   ├── libqwayland-generic.so
│   ├── libqwayland-xcomposite-egl.so
│   ├── libqwayland-xcomposite-glx.so
│   └── libqxcb.so
├── platformthemes
│   └── libqgtk3.so
├── playlistformats
│   └── libqtmultimedia_m3u.so
├── printsupport
│   └── libcupsprintersupport.so
├── qmltooling
│   ├── libqmldbg_debugger.so
│   ├── libqmldbg_inspector.so
│   ├── libqmldbg_local.so
│   ├── libqmldbg_messages.so
│   ├── libqmldbg_nativedebugger.so
│   ├── libqmldbg_native.so
│   ├── libqmldbg_preview.so
│   ├── libqmldbg_profiler.so
│   ├── libqmldbg_quickprofiler.so
│   ├── libqmldbg_server.so
│   └── libqmldbg_tcp.so
├── sensorgestures
│   ├── libqtsensorgestures_counterplugin.so
│   ├── libqtsensorgestures_plugin.so
│   └── libqtsensorgestures_shakeplugin.so
├── sensors
│   ├── libqtsensors_generic.so
│   ├── libqtsensors_iio-sensor-proxy.so
│   └── libqtsensors_linuxsys.so
├── sqldrivers
│   └── libqsqlite.so
├── wayland-decoration-client
│   └── libbradient.so
├── wayland-graphics-integration-client
│   ├── libdrm-egl-server.so
│   ├── libqt-plugin-wayland-egl.so
│   ├── libshm-emulation-server.so
│   ├── libvulkan-server.so
│   ├── libxcomposite-egl.so
│   └── libxcomposite-glx.so
├── wayland-graphics-integration-server
│   ├── libqt-wayland-compositor-drm-egl-server-buffer.so
│   ├── libqt-wayland-compositor-shm-emulation-server.so
│   ├── libqt-wayland-compositor-vulkan-server.so
│   ├── libqt-wayland-compositor-wayland-egl.so
│   ├── libqt-wayland-compositor-wayland-eglstream-controller.so
│   ├── libqt-wayland-compositor-xcomposite-egl.so
│   └── libqt-wayland-compositor-xcomposite-glx.so
├── wayland-shell-integration
│   ├── libfullscreen-shell-v1.so
│   ├── libivi-shell.so
│   ├── libwl-shell.so
│   ├── libxdg-shell.so
│   ├── libxdg-shell-v5.so
│   └── libxdg-shell-v6.so
└── xcbglintegrations
    ├── libqxcb-egl-integration.so
    └── libqxcb-glx-integration.so

22 directories, 83 files
EXL ★★★★★
()

И снова сойджаки рыдают от systemd, восхитительно, всё правильно Поттер делает. Такую базированную базу выдаёт, что всех чуханов в округе корёжит)

anonymous
()
 ← 1 2 3 →
Development