Я могу позволить пользователям chmod файл, не принадлежавший им?

Question

Я могу позволить пользователям chmod файл, не принадлежавший им?

/etc/securetty консультируется pam_securetty модулем для решения, от которых виртуальных терминалов (ttyS) корень позволяется войти в систему от. В прошлом /etc/securetty консультировался программами как вход в систему непосредственно, но теперь дескрипторами PAM это. Так изменяется на /etc/securetty будет влиять на что-либо с помощью PAM с конфигурационным файлом, который использует pam_securetty.so. Так, только программа входа в систему затронута по умолчанию. /etc/pam.d/login используется для локальных логинов и /etc/pam.d/remote используется для удаленных входов в систему (как telnet).

Основные типы записи и их влияние следующие:

Если /etc/securetty не существует, корню позволяют войти в систему от любого tty
Если /etc/securetty существуйте и пусто, корневой доступ будет ограничен однопользовательским режимом или программами, которые не ограничиваются pam_securetty (т.е. su, sudo, ssh, scp, sftp)
если Вы используете devfs (файловая система устаревшая для обработки/dev), добавляя, что записи формы vc / [0-9] * разрешат корневой вход в систему от данного числа виртуальной консоли
если Вы используете udev (для динамического управления устройствами и замены для devfs), добавляя, что записи формы tty [0-9] * разрешат корневой вход в систему от данного числа виртуальной консоли
при списке консоли в securetty, обычно не имеет никакого эффекта, так как/dev/console указывает на текущую консоль и обычно используется только в качестве tty имени файла в однопользовательском режиме, который незатронут /etc/securetty
добавление записей как pts / [0-9] * позволит программы, которые используют псевдотерминалы (имущество) и pam_securetty для входа в систему в корень, предполагающий, что выделенное имущество является одним из тех перечисленных; это обычно - хорошая идея не включать эти записи, потому что это - угроза безопасности; это позволило бы, например, кому-то входить в систему в корень через Telenet, которая отправляет, пароли в простом тексте (обратите внимание, что pts / [0-9] * является форматом для udev, который используется в RHEL 5.5; это будет отличаться при использовании devfs или некоторая другая форма управления устройствами),

Для однопользовательского режима, /etc/securetty не консультируется, потому что sulogin используется вместо входа в систему. См. sulogin страницу справочника для большего количества информации. Также можно изменить программу входа в систему, используемую в /etc/inittab для каждого runlevel.

Обратите внимание, что Вам не должен использовать /etc/securetty управлять корневыми логинами через ssh. Сделать то изменение значение PermitRootLogin в /etc/ssh/sshd_config. По умолчанию /etc/pam.d/sshd не настроен для консалтинга с pam_securetty (и поэтому /etc/securetty). Вы могли добавить строку, чтобы сделать так, но ssh не устанавливает фактический tty до когда-то после подлинного этапа, таким образом, это не работает как ожидалось. Во время автора и этапов учетной записи – по крайней мере, для openssh – tty (PAM_TTY) является hardcoded к "ssh".

Вышеупомянутый ответ основан на RHEL 5.5. Большая часть его будет принадлежать текущим дистрибутивам другого *, отклоняют системы, но существуют различия, некоторые из которых я отметил, но не все.

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

Источники:

17

ashleysmithgpu 15.05.2013, 11:55

Ссылка

2 ответа

Полномочия Unix разработаны, чтобы быть простыми. Вам нужно разрешение чтения читать из файла, разрешение записи записать в файл и выполнить разрешение выполнить файл. Необходимо владеть файлом для изменения его метаданных ¹.

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

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

Довольно редко должно изменить полномочия файла, которым Вы не владеете. Обычно необходимо принять меры, чтобы файл имел правильные полномочия, как только он создается. При реальной необходимости в этом Вы могли бы дать пользователю sudo chmod права для конкретного режима и конкретного файла (например. joe: ALL = (ALL) chmod g+r /path/to/file).

¹_{За исключением времен доступа и времени изменения, которое конкретно, потому что чтение или запись в файл также устанавливают их.}

10

Gilles 'SO- stop being evil' 27.01.2020, 19:47

Ссылка

1

В моем варианте использования существует оба веб-процесс (www-данными) и процесс cli (один), которые хотят установить полномочия на файле. Я добавил меня к группе www-данных, но это не достаточно. – donquixote 05.03.2017, 01:40
2

Даже изменение владельца/группы к myself:www-данным не помогает. (Я не разработал механизм, который пытается установить полномочия, я не имею никакого контроля над ним) – donquixote 05.03.2017, 01:42

Я могу позволить пользователям chmod файл, не принадлежавший им?

Теги

Похожие вопросы