kwin_wayland будет завязан на logind

почему у меня в генте вывод аналогичной команды выглядит иначе? почему у меня в генте иксы всегда работали от рута и работают до сих пор (на блобе нвидиа)?

и главный вопрос: почему ты такой втупую упёртый балабол?

что для тебя достаточный пруф? у меня прямо сейчас единственные иксы запущены от юзера и всё работает

даже так

# getcap $(which Xorg)
Failed to get capabilities of file `/usr/bin/Xorg' (Operation not supported)

# grep CONFIG_EXT4_FS_SECURITY /usr/src/linux-3.16.0/.config
# CONFIG_EXT4_FS_SECURITY is not set

потому что gentoo — конструктор :3

попробуй ещё раз

просто залогинься юзером в консоли и запусти иксы с -logfile доступным для записи пользователю

нужно только чтобы ядерный модуль уже был загружен и пользователь имел права на /dev/nvidia* /dev/input/event*

упёртые здесь только вы два

нате

http://wiki.gentoo.org/wiki/Non_root_Xorg

google://non root xorg

Спасибо, анон, то что нужно!

Добавил пользователя в группу input (дав права на запись в /dev/input/event*), снял suid бит с /usr/bin/Xorg, запустил иксы от своего пользователя, и все работает!

Теперь вопрос, зачем этот весь сыр-бор с logind был нужен (вспоминаю, с какой помпой релизнули xorg 1.16)? Насколько секурно добавлять пользователя в группу input? Можен я чего-то не понимаю.

Несекьюрно вообще никак. Если вкратце — весь multiseat (когда за одним компьютером несколько терминалов) идёт нафиг. Более того, logind по сути ради multiseat'а и создавался, и там в доках написано, что добавлять пользователей в группы типа input/video/audio теперь не рекомендуется.

тут есть немного: http://hansdegoede.livejournal.com/14268.html

logind по сути ради multiseat'а и создавался

Ну это-то понятно, самому можно хоть от рута сидеть. Но если пользователей >одного, то они, имея доступ к /dev/input/event*, смогут перехватывыть друг у друга ввод, со всеми последствиями. Если беда только в этом, то для меня этот весь logind вообще не нужен, равно как и для 99% пользователей.

Да, я в курсе про этого товарища (он ведь заварил всю эту кашу с rootless xorg), просто я думал что он решает реальную проблему, а оказывается сражается с ветряными мельницами.

Вот, берем man systemd-logind и идем по пунктам:

systemd-logind is a system service that manages user logins.

ОК, getty тоже управляет пользовательской сессией.

It is responsible for:

It is vulnerable in:

Keeping track of users and sessions, their processes and their idle state

У МЕНЯ всегда ровно одна сессия, она всегда активна.

Providing PolicyKit-based access for users to operations such as system shutdown or sleep

Проблему решает user ALL=(ALL) NOPASSWD /sbin/poweroff.

polkit - ненужная сущность.

Если вы говорите, что NOPASSWD - небезопасно, то я думаю что управление правами через джаваскрипты - тем более. Уязвимостей в бинарнике /sbin/poweroff уж точно меньше, чем в spidermonkey или /usr/lib/systemd/systemd (размер бинарника 1.3M!).

Implementing a shutdown/sleep inhibition logic for applications

В моем торрент-клиенте галка «Inhibit suspend» стояла когда этого logind еще в планах не было.

Handling of power/sleep hardware keys

/etc/acpi/handler.sh дает неограниченную гибкость при всей простоте.

Multi-seat management

Опять же, МНЕ не нужно.

Session switch management

Ненужно

Device access management for users

С чего это вдруг unix groups стали неактуальны.

Automatic spawning of text logins (gettys) on virtual console activation and user runtime directory management

ЧАВО?

User sessions are registered in logind via the pam_systemd(8) PAM module.

Спасибо, не надо.

Короче, ЛОР, я прозрел, Поттеринг не нужен, UNIX рулит, devl547, ты был прав.

It was only tested under nouveau, but all kms driver should work.

давно нвидиевский блоб стал работать через KMS?

ты всё ещё выходишь на связь у него своя собственная реализация kernel modesetting

я уже написал как самому проверить

Как выше писали, nvidia блоб тоже должен работать, если дать пользователю права на /dev/nvidia*. То есть KMS необязателен.

если дать юзеру права на прямую запись в эти dev-файлы, то какой вообще нахрен смысл в иксах не от рута? для галочки, чтобы пофапать на цифры uid иксового процесса? тупнятина какая-то

Просто не говори за всех.

Дать юзеру права на /dev/nvidia* всяко лучше чем дать capabilities CAP_SYS_ADMIN бинарю Xorg.

почему лучше?

Просто не говори за всех.

Я кажется, специально это выделил. Мне лично, как и многим, все эти фичи не нужны, зачем тогда заставлять всех это использовать.

Что значит «заставлять»? Не нравится — не ешь, переходи на генту/слаку/олдстейбл/венду. Но это твоё мнение, которое «не нравится» или «мне не нужно», оно субъективно, и поэтому не может быть использовано как аргумент в дискуссиях о том, хорош или плох тот или иной проект.

запусти иксы от другого отдельного пользователя

юзер в любом случае может что-то писать в ядро, в тот же pseudo tty или через сисколы, лол

пользователь может только дёргать определённые ioctl с определёнными результатами на этих файлах

другой вопрос, что там в блобе за баги могут быть

почему лучше?

Права на конкретные файлы - возможность экслюзивного доступа для юзеров/членов группы (тогда два юзера одной видеокарты смогут друг у друга перехватывать видео выход), Xorg с правами, практически равными root - огроменная дырень в системе. Если я - единственный пользователь в системе, права на /dev/input, /dev/nvidia и т.д. - не дыра.

Не нравится — не ешь

Да не, за столько лет на линуксе привык уже жрать говно.

почему бедный маленький линуксоид должен переходить с debian на всякие маргинальные поделия из-за проказничества какого-то шизанутого немца? это навязывание чистой воды! задолбали ненужноd-фанатики

Это вопрос к техническому комитету Debian и лично к Bdale Garbee, чей голос был решающим в выборе умолчальной init-системы для Jessie. Скажи ему, что он «ненужноd-фанатик»...

Причём здесь default init дебьяна к logind в KDE? То, что эти вещи вообще связаны - уже провал всей экосистемы.

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

То, что эти вещи вообще связаны - уже провал всей экосистемы

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

Да пофиг, сообщество FreeBSD всё равно добавит поддержку ConsoleKit.

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

Не раньше чем за 100 лет.

Или напишет альтернативную реализацию logind, что уже вошло в чей-то (из *BSD) список проектов на текущий GSoC...

Зависит от того, как понимать анонимуса. Под шизанутым немцем может подразумеваться как Мартин Грасслин, так и Леннарт Поттеринг.

Впрочем, аксиома опенсорса гласит: «Whoever contributes code makes the decision». Не нравится logind по религиозным причинам — пили свой kwin_wayland, с блэкджеком и suid-битом.

а о остальных *nix подумали?

Мультисит и работа более 2 пользователей за одним компом? ConsoleKit умел задолго до systemd и logind. Проверить например Ubuntu 9.04 в виртуальной машине.

пили свой kwin_wayland, с блэкджеком и suid-битом.

Да мне-то ни kwin, ни wayland даром не надо, и сижу уже три часа как без затычки в *опе иксов с setuid (еще раз спасибо анону).

Насколько я понял, все твои претензии к logind и systemd состоят в том, что лично тебе не нужны его фичи. Но, понимаешь ли, эти фичи нужны разработчикам того софта, который тебе нужен.

Следовательно, у тебя есть ровно два варианта:

• ты не хочешь видеть в своей системе {system,login}d по религиозным или ещё какой-нибудь иррациональным причинам, и тогда твои действия я описал в сообщении выше;
• ты — адекватный человек, и понимаешь, что (раз тебе не нужны фичи logind) тебе на самом деле не должно быть ни холодно, ни жарко от его присутствия в системе.

  Это как говорить: «Ну я же не программист, зачем мне либы Qt в системе? А KDE — уроды, тянут ко мне в систему какое-то ненужное говно».

Много раз утверждалось, что ConsoleKit не оправдал своих ожиданий. Соответствующие презентации и записи докладов мне гуглить лень, но можешь глянуть здесь: https://fedoraproject.org/wiki/Features/ckremoval

ты не хочешь видеть в своей системе {system,login}d

Да мне оно все не мешает вообще. Просто не нравится, что все смешано в кучу я не могу выбрать только то, что мне нужно, даже используя source-based дистрибутив с use-флагами. Типичный вендорлок.

Например, я хочу:

• udev
• systemd
• networkd
• timesyncd
• resolved

Не хочу:

• logind
• localed
• journald
• machined

Почему оно все согнано в кучу и прибито гвоздями друг к другу, мне непонятно. Те же KDE-шники сейчас активно дробят свои kdelibs, kde-runtime и kde-workspace на кучу мелких пакетов с отдельными репозиториями и четко определенными зависимостями друг от друга.

> Те же KDE-шники сейчас активно дробят свои kdelibs, kde-runtime и kde-workspace на кучу мелких пакетов с отдельными репозиториями и четко определенными зависимостями друг от друга.

Видимо, созрели. Через 10 лет и до udev-systemd-шников «дойдёт» что надо было делать так. (да, я пытаюсь найти оправдание вендорлоку)

localed

machined

Элементарно выпиливается параметрами к configure. Вроде бы API этих компонентов никем не используется, так что feel free.

logind

Выпиливается не менее элементарно (да, серьёзно, оно не прибито гвоздями!). Если ты не используешь ни одну из крупных DE — тоже спокойно можешь это сделать.

journald

Тут уже посложнее. Видишь ли, journald — штука, которой приходит stdout/stderr запущенных служб, т. е. это достаточно базовая функциональность... Она просто вынесена в отдельный процесс. Ей можно в конфиге указать Storage=none, вследствие чего она не будет вести своих бинарных логов, а тупо передавать всё в syslog-совместимый сокет (если включить это в соседней опции в том же конфиге).

Но, в принципе, если ненависть сильна и пяти мегабайт RSS очень жалко — можешь тупо замаскировать её юниты (systemctl mask systemd-journald.{service,socket}). Система прекрасно запускается и работает без journald, что бы там ни говорили хейтеры.

выпиливается параметрами к configure

Ясно. Видать, у нас просто разное понимание модульности. Тем более они друг с другом не линкуются, а общаются через дубас.

ConsoleKit умел задолго до systemd и logind.

Видимо, оно работало слишком хорошо. Надо переписать.

Тем более они друг с другом не линкуются, а общаются через дубас.

Вот именно.

Нет, пересобирать необязательно. Можно замаскировать юниты.. можно их просто удалить, вместе с соответствующими бинарниками. Они ни к чему не прибиты гвоздями, лишь сделаны теми же людьми, в том же духе и с теми же утилитарными либами.

ещё про dos вспомни

ConsoleKit умел задолго до systemd и logind

Неудивительно, ведь logind делали ровно те же люди.

ConsoleKit […] работало слишком хорошо.

Не знаю как ты, а я прекрасно помню истерики на LOR по поводу появления ConsoleKit (и прочих китов, удевов и д-басов). Что характерно, претензии истерящих мало отличались от таковых по поводу {system,login}d.

ещё hal, лол

идиот?