Здравствуйте, как можно обезопасить права пользователя root от программ запускаемых от моего пользователя?
Они могут быть кейлоггерами и записать вводимый мною пароль, а потом использовать его?
Запускать то во что я ввожу пароль отдельно от основных иксов?

Скомпилировал и установил Portage в Debian. На очереди другие утилиты типа emerge и layman. Не могли бы вы подсказать что тут действительнo тpебуется и подводные камни? Какие части Gentoo handbook нужны?
И главный вопрос:
Я хочу добавить разрешение на изменение / не root, но при этом не хочу чтобы этот не-root мог перезаписывать файлы основной системы. Можно ли сконфигурировать portage на работу от пользователя?
В таком случае я не порушу систему.

Слишком много интерпретаторов в системе, слишком много загрузчиков и мест куда можно прописать свой код для загрузки.
Даже с этим всем Linux продолжает быть безопаснее Windows, но последствия ручного запуска программ могут быть трудноотслеживаемыми местами.
Wine:
Запускает всё с правами текущего пользователя и уж точно не является песочницей. Wine наплевать на права исполнения(noexec), а кроме того в неё загружают код который пришёл неизвестно откуда. Можно придумывать шикарные вирусы которые не отслеживаются антивирусами Windows потому что активируются только в wine. Диски и области видимости - вредны а не полезны и больше смахивают на декларацию о просьбе (пожалуйста не пиши сюда).
.bashrc , файлы X, конфигурационные файлы
Их объединяет то что они или исполняемые сразу или то что изменив их можно добиться выполнения команды после запуска программы (mplayer.conf который умеет запускать произвольные команды).
Консоль и команда alias
alias sudo='wine trojan.exe -sudo'

Какой вы её видите. В частности интересен способ избегания «ада зависимостей».
1:
Cтатическая линковка:
1 Система превращается в винду, сложность замены библиотек на более новые с исправленными уязвимостями. Но для обновления можно попытаться перелинковать их не перекомпилируя.
2 Дублирование библиотек в рамках дистрибутива. Но в ядре есть функциональность дублирования одинаковых участков оперативной памяти.
3 Не все программы можно так собрать. Glibc не готова для статики, но есть musl.
2:
Установка каждого пакета в собственную папку и управление библиотеками через симлинки:
1 Сложноватая система. Нужен принципиально новый пакетный менеджер.
2 Нужно менять путь к библиотекам при компиляции. Есть случаи когда это невозможно?
3 Многоуровневое файловое дерево.
3:
Установка конфликтующих пакетов в отдельное пространство имён для процесса:
1 Эта технология используется кажется для виртуализации, но можно упростить её для такой цели. Это не докер, а просто ядро будет подставлять например разный /usr/ для разных процессов. Немного похоже на Plan9.
2 Стандартная компиляция. Довольно просто прикрутить к стандартным дистрибутивам.
3 Путаница с пространствами имен.
4 Не охватывает ядро и драйвера.

Многие паттерны использования пеки подразумевают использование почти одной мыши. При этом клавиатура может лежать достаточно далеко.
Даже Ъ-юниксоиды признают что использование мыши часто оправдано и часто она эффективнее. (http://doc.cat-v.org/plan_9/translations/russian/wiki/mouse_vs_keyb)

Интересуют мозаичные ВМ с хорошим управлением мышью или скрипты для них.
Было бы интересно.

Здравствуйте. Дело в том что я люблю извращаться с системой и ставить пакеты методом ./configure ; make ; make install в корень.
Удивительно, но даже при замене базовых системных компонентов у меня мало проблем с этим. Хотя я могу перекомпилировать apt-build ом неработающий пакет. Но где же грабли?
Можно ли обновлять мою систему, с какими проблемами я могу столкнуться и как их избежать?

Ну зачем? Я понимаю что иногда не обойтись без дополнительных параметров.
Но большинство программ собираются так. Вот почему бы не сделать скрипт генерации пакета который -
1 Определяет метод сборки и конфигурации (шелл-скрипт ./configure, cmake, ещё.
2 Исходя из этого находит зависимости по таблице соответствия требуемых файлов и библиотек с пакетами (можно даже парсить include-ы)
3 Стандартная установка, fakeroot, отслеживание..

Почему именно таким способом не собирается большинство пакетов в дистрибyтивах?

Первая часть: init. Обслуживает процессы которым становится родителем и запускает autorun.bash с передачей параметра (1,2...)
Вторая часть: Парсер ini файлов systemD. На входе принимает ini файлы systemD, а на выходе - autorun.bash который запускает демоны в нужном порядке. В нужном месте в autorun.bash проставлены > для отправки вывода демона в лог. Монтирование и прочее делается скриптом.
Третья часть (опционально) такая штука которая ждёт обращения к демону чтобы его запустить.

Всё. Такое было бы нужно?

Hsetroot и прочие не предлагайте пожалуйста. Было бы идеальным если бы нашлось что-то заброшенное, непопулярное и недопиленное. Спасибо.

Считаю свой вопрос глупым судя по его содержанию. Можете переносить если что.

Я конечно знаю что всё должно запускаться с каким-то приоритетом, но это не кажется сложной задачей. Почему же эти скрипты занимают несколько экранов текста?
И почему замена autoexec.nt такая раздутая?

Адрес: linux.org.ru/forum/talks/9229668

0-я причина: лор это сайт на котором обсуждение открытого ПО не оффтопик. Большинство обсуждаемых программ - открытые.
1-я причина: Linux тут при том что launchpad.net ppas нельзя зайти без шифрования http.
3-я причина: ssh на линуксе.

Здравствуйте. Я неадекват и я считаю концепцию современных пакетных менеджеров настоящей проблемой. Главный недостатoк в том что пакеты очень несовместимы. Т.Е:

1 Вы можете лишиться любимой программы просто потому что её больше некому поддерживать или она несовместима с другими компонентами. Наверно много людей мечтало оставить Gnome 2 в арче? :-)

2 Вы не сможете запустить новомодную примочку которая появилась буквально вчера не обновив при этом половину системы включая графический редактор и фиг знает что ещё. (рядом лежит windows версия которая запускается в windows 95/98/2000/xp/vista/7/8 и wine)

И как это побороть? Или может быть система песочниц?

Для mono
Доброе утро. Это не просьба восстановить тему (на неё уже ответили посоветовав 0install и nixpkg) Я просто умираю от любопытства почему моя тема посчитана тупняком. Я не смогу исправиться если не пойму в чём же моя ошибка.

Например Linux и dоs принимают команды в которых имя обрабатываемого файла передаётся с её параметрами, но они могли бы читать их с отдельного потока.

cat text | nano 

./file 

cat ./file 

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

Чтобы висеть на отдельном теге и иметь в себе ярлыки для запускаемых программ и часто используемых документов.

Берегите голову. И так:
Этот изврат пихается Майкрософтом как защита от компьютерных угроз и в первую очередь вирусов. Если доказать что на самом деле оно не только бесполезно, но и само является дырищей - репутация Secure Boot будет подорвана.
Есть рацпредложение для авторов SMS Winlocker-ов чтобы они максимально использовали новые возможности нового биоса. А именно превращение компьютера в кусок стройматериала.

Может быть эта тема даже и не для Talks, но сам подход и цели больше подходят скорее для этого раздела. (перенесите если думаете что это не так) И так:
Возможен ли запуск оболочки explorer.exe и других утилит Windows используя wine?
Для проверки взял explorer.exe из windows 95 и он даже показал панель задач с папками, но большинство диалогов (даже файловый менеджер не открывается). Может не хватает ресурсов или dll файлов?

Какие проблемы вообще? Проблема в том что DOS - однозадачная ОС?
Но ведь современные процессоры двухядерные и досу в «не эмуляторе» можно отдать целое ядро под личное пользование.

Опять как чувствую что тема тупняковая но мне нужно знать для образования.