Философия Unix и логические парадоксы

Может ли root создать файл, который сам не сможет потом удалить?

В рамках DAC — нет, UID 0 скипает все проверки Unix-прав.

Можно ли из этого парадокса сделать вывод, что пользователя root не существует?

в рамках софта на конкретной системе

Ну вот ты и ответил на свой парадокс. «В рамках софта на конкретной системе» создание файла, не удаляемого рутом, не реализовано.

Чистил и не чистил одномоментно, man диалектика

А как насчёт chattr +i например?

1. Так это и не только рут может.
2. Ничего не мешает руту снять +i, это просто часть процедуры удаления.

В рамках DAC — нет, UID 0 скипает все проверки Unix-прав.

ты прав, но в том-то и дело, что ТС слабоват в философии UNIX. он спрашивает именно _про_ _пользователя_ root. гуманитарное решение это задача: мы создаем файл от root и переименовываем пользователя с uid 0. =) ну это в качестве шутки, конечно. не нужно только в ответ катать серьезную телегу=)

создаем файл от root и переименовываем пользователя с uid 0

Противоречит условию задачи, в нём сказано, что именно «пользователь root всемогущий».

не нужно только в ответ катать серьезную телегу

Я по-другому не умею, а так-то тут вся тема смехуёчки про брадобрея с привкусом линукса.

Можно ли из этого парадокса сделать вывод, что пользователя root не существует?

• парадокса нет
• пользователь рут существует - это объективная данность, известно кто когда и с какой целью его создал
• и вообще, пользователь рут это объект, а субъект - это администратор, вот здесь вся аналогия из ОП и разваливается

Противоречит условию задачи, в нём сказано, что именно «пользователь root всемогущий».

не, нормально: в какой-то момент времени он является всемогущим. после своего исчезновения вопроса такого нет, т.к. его самого нет. в условии нет одномоментности.

На самом деле лишь программист всемогущий, а root - лишь архангел его.

Удали рутом rm. 95% не сможет удалить.

Всемогущество root проявляется в том, что root способен выбирать, может или не может быть удалён файл даже им самим. Пользователю подобного не дано.

Может ли root создать файл, который сам не сможет потом удалить?

На CD/DVD-R?

Чистил ли root свой домашний каталог ( /root )?

Это частный случай парадокса Рассела (вариант брадобрея) ©.

Так и на «свиньи не морские животные. морские ли свиньи?» можно ответить «да». Здравствуйте, это тренинг по скоростном переобуванию?

Может ли root создать файл, который сам не сможет потом удалить?

Этот философский вопрос сводится к узкотехническим. Типа существуют ли в оборудовании какие-либо неконтролируемые через систему места? Простейший вариант - записав файл, далее износить носитель до выхода из строя функции записи

umount

Это не удаление. Вы еще скажите вилку из розетки вытащить

overlayfs или как её там

Может ли root создать файл, который сам не сможет потом удалить?

Изи, man squashfs :D

Кроме того уид0 уєе очень давно не является всемогущим. Только на дефолных минималках сохраняется. Все остальное при должном умении настраивается и полисится. А в нормальных системах в догонку еще и трастчейнится и бутверифаится.

man squashfs

Кто же мешает снести сжатый архив целиком? При таком подходе вы еще предложите создать файл в закриптованном объеме, выйти и забыть пароль.

Чистил ли root свой домашний каталог ( /root )?

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

Может ли root создать файл, который сам не сможет потом удалить?

Рут может удалить себя из /etc/passwd, после чего он не сможет залогиниться и удалять файлы

Пользователь root всемогущий, он может делать всё что угодно.

Кто такой «пользователь»? Если это человек, залогинившийся рутом, то что будет, если он лишит себя возможности залогиниться - поменяет пароль на случайный, перенастроит фаервол или испортит железо?

Может ли root создать файл, который сам не сможет потом удалить?

Что такое «удалить»?

Что не может рут с удаленным паролем, то может рут с бэкапом системы или с лайв-системой

это уже физические манипуляции с системой

Кстати, эта самая проверка UID=0 проводится непосредственно в каждом драйвере ФС по-отдельности. И если разработчик какой-то ФС забыл это сделать, то в конкретно его ФС эта проверка работать не будет

Тогда руту достаточно сделать шатдаун. Без физических манипуляций он в общем случае ничего не сделает

не все ФС поддерживают разграничение прав пользователей, так что где ещё это проверять

ФС могла бы предоставлять поля RWX (или еще как-то декларативно) для каждого файла, а этим делом занимался бы VFS.

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

Какие у вас расплывчатые жизненные принципы. Ну тогда еще можно зархивировать файл паролем из dev/random и вы его тоже не прочтете

Ключевое слово ФС :) Оно не файл, оно уже дата на ПЗУ.

Оно не на ПЗУ. Удалил системными средствами ФС - значит удалил и и файл. Если же нужно остальную часть - пожалуйста, через unsquashfs, mv, rm, mksquashfs

Кстати, эта самая проверка UID=0 проводится непосредственно в каждом драйвере ФС по-отдельности. И если разработчик какой-то ФС забыл это сделать, то в конкретно его ФС эта проверка работать не будет

ФС могла бы предоставлять поля RWX (или еще как-то декларативно) для каждого файла, а этим делом занимался бы VFS.

А по-другому нельзя. Тогда невозможно было бы писать всякие сетевые и прочие ФС, которые не реализуют семантику DAC в исходном виде.

(1) вообще - да, но нет. Можно формально объявить файл таким, чтобы root не мог его удалить, а он сможет. Можно используя ошибки реализации файловой системы создать такой файл и он не сможет (без дебагера).

(2) нет, потому что пользователи в /home и это было захардкожено в скрипте. Вообще, наличие $HOME у root’a переоценено.

В линуксе есть фичи повеселей. Если у исполняемого файла убрать юзерский атрибут x, но оставить его для group и other, то пользователь не сможет запустить файл, даже если находится в группе :)

У меня был выстррел в ногу, у тебя же в голову.