Почему непривилегированный пользователь не может изменить принадлежность файла?
От показанного (2):
Только привилегированный процесс (Linux: один с возможностью CAP_CHOWN), может изменить владельца файла. Владелец файла может изменить группу файла любой группе, которой тот владелец является членом. Привилегированный процесс (Linux: с CAP_CHOWN), может изменить группу произвольно.
Какова причина этого ограничения? Почему непривилегированный пользователь не может изменить принадлежность файла файла, которым она владеет (т.е. никакой/etc/shadow)?
$ touch blah
$ chown root:root blah
chown: changing ownership of `blah': Operation not permitted
4 ответа
Позволяя пользователям "отдать" файлы Вы сталкиваетесь с различными функциями ОС. Такой как:
Taking up another user's disk quota.
Impersonating another user (or even root) via setuid.
Having insufficient privileges to undo a mistaken chown.
Making it appear that someone else had created a given file.
Setting up cron jobs to run on other user's accounts.
And many more...
Ну, если кто-либо мог бы изменить владение, затем любой мог бы изменить полномочия получить доступ к любому файлу в системе. Это плохо не только с вредоносной точки зрения (никакой требуемый sudo), но с точки зрения системного администратора. Если какой-либо из пользователей мог бы изменить какой-либо из файлов, то полномочия файла бесполезны.
Поскольку затем пользователь может уклониться от квот файловой системы. Если у меня есть квота 100 МБ, и у Вас есть квота 100 МБ, я могу загрузить 100 МБ, chmod a+r, показанный Вас, то загрузить еще 100 МБ.
Это - просто личный выбор разработчиков Linux не позволить его - все псевдосоображения безопасности, данные, являются показными, поскольку существуют системы Unix, которые позволяют это.
Я думаю, что эта функциональность свелась, следовало ли поведение Вашего Unix за 'System V' (AT&T) или Unix Беркли (BSD)...
Что касается других упомянутых проблем безопасности:
Исполнение роли другого пользователя (или даже базируются) через setuid.
Надуманный вопрос: Изменение 'владельца' очищает любые 'setXid' биты (U/G)
Наличие недостаточных полномочий отменить показанное ошибочное
Едва ли 'угроза безопасности', НО, это могло бы быть в системах, которые позволяют изменять пользователя, можно возвратить его, если это находится в каталоге, Вы владеете, другое мудрое: 'будьте осторожны'!
То, чтобы заставлять это появиться, что кто-то еще создал данный файл.
Это все еще было бы в каталоге, который перезаписываем Вами. Т.е. Вы не могли переместить его в их homedir, если этого не открывается для записи Вашей группе или всем (или Вы конкретно, если ACL доступен).
Установка заданий крона для работы учетных записей другого пользователя.
Снова, не работал бы - так как crondirs принадлежат пользователю и не установлены даже быть читаемыми другими пользователями, уже не говоря о перезаписываемом.
если кто-либо мог бы изменить владение, то любой мог изменить полномочия получить доступ к любому файлу в системе.
Нет: только если пользователь 'владеет' каталогом, содержащим тот файл. Т.е. Я могу дать файл, названный 'passwd' для укоренения, но я не мог переместить его в/etc/, если у меня нет разрешения записи к/etc/.
квоты
Потенциально актуальный вопрос - ЕСЛИ БЫ Вы используете квоты, но он походит на него, было бы легко обнаружить при подведении итогов дискового пространства dir дома; единственная проблема была бы в директорах, которые перезаписываемы многочисленными пользователями. В этом случае, возможно, идя владельцем того 'dir'. МОЖЕТ иметь место в тех системах, что поддержка, 'отдающая' файлы, что можно только сделать это в каталогах, которыми Вы 'владеете', но это было Долгое время, так как я на самом деле был в системе, которая позволяет это, таким образом, я не помню точных ограничений.
Я, кажется, не забываю там быть некоторым 'компромиссом' для разрешения 'отдачи файлов'..., например, - в системах, которые признали, что, чему-то еще не позволили, тот Linux позволяет, но не может помнить то, чем это было от руки...
Я сказал бы, что вышеупомянутый 'ответ' должен быть неотмеченным как ответ, поскольку это не реальный ответ. IT больше проектное решение - я просто не знаю, какой компромисс (компромиссы) были.
Могут быть проблемы безопасности, не повышенные выше этого, была бы обоснованная озабоченность, но те выше не допустимы.
IMO, это должно быть устанавливаемое системой 'значение' в "/proc", но вообще говоря, я думаю, что большинство людей не заботится так очень.
Если бы была сильная необходимость в нем, 'то chown' мог бы быть улучшен безопасностью и изменен, чтобы позволить его и затем установить w/setuid 'корень', чтобы позволить ему проводить такую политику.