Механизм разрешения файла в Unix как системы

Это /etc/nsswitch.conf это говорит систему, где искать хранилище пользователей, групп в картах passwd, группы и тени. Было ли это локальными файлами, nis/yp, или ldap, это - nsswitch.conf. Конфигурация для поддержки этого изменения позже появилась бы или в pam конфигурацию или в nss библиотеки. pam на Linux делает упрощение, так как это также поддерживает tcp_wrappers наряду с удовлетворением требованиям заказчика аутентификации UNIX различными способами.

После того как Вы работали и изменились /usr/bin/authconfig использовать ldap,

Authconfig изменит Ваши файлы PAM для Вас (среди прочего), конкретно файл/etc/pam.d/system-auth. Типичный подлинный системой файл в системе Red Hat, настроенной для аутентификации использования LDAP, похож на это:

'pam_unix' модуль вызывается затем и сделает работу запроса пользователя для пароля. Аргументы "nullok" и "likeauth" означают, что пустые пароли не рассматривают как заблокированные учетные записи, и что модуль возвратит то же значение (значение, которое похоже на "подлинное" значение), даже если это называют как учетный модуль установки. Обратите внимание, что этот модуль "достаточен" и не "необходим". 'pam_ldap' модуль вызывается и сказан "use_first_pass", другими словами, используйте пароль, который был собран pam_unix модулем вместо того, чтобы предложить пользователю другой пароль. Обратите внимание, что то, что этот модуль отмечен "достаточный", и он расположен после того, как pam_unix означает, что, если pam_unix преуспевает в том, чтобы проверить пароль локально, pam_ldap не будет вызван вообще.

#%PAM-1.0
 # This file is auto-generated.
 # User changes will be destroyed the next time authconfig is run.
 auth        required      pam_env.so
 auth        sufficient    pam_unix.so nullok try_first_pass
 auth        requisite     pam_succeed_if.so uid >= 500 quiet
 auth        sufficient    pam_ldap.so use_first_pass
 auth        required      pam_deny.so

 account     required      pam_unix.so broken_shadow
 account     sufficient    pam_succeed_if.so uid < 500 quiet
 account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
 account     required      pam_permit.so

 password    requisite     pam_cracklib.so try_first_pass retry=3
 password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
 password    sufficient    pam_ldap.so use_authtok
 password    required      pam_deny.so

 session     optional      pam_keyinit.so revoke
 session     required      pam_limits.so
 session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
 session     required      pam_unix.so
 session     optional      pam_ldap.so

/etc/ldap.conf должен иметь

pam_lookup_policy yes
pam_password exop

/etc/ssh/sshd_config должен иметь и должен быть перезапущен после изменения конфигурации.

UsePAM yes
0
07.12.2012, 10:42
1 ответ

Владение и права доступа в основном сотрудничают. Ownership говорит систему, кто может получить доступ к файлу, в полномочиях файла говорится как.

Владение разделяет доступ на три группы: пользователь (отдельный пользователь, владеющий файлом), группа (пользователей), другие (остальная часть мира).

Полномочия: r - чтение позволяется, w - запись позволяется, x - выполнение позволяется

Для каталогов значение немного отличается: x позволяет Вам вводить каталог, в то время как r список его содержания (и w позволяет Вам обновить его) - который означает, что, если Вы знаете точное имя файла, Вы не должны читать полномочия на каталоге, это находится в, x достаточно. Вам нужно r на файле все же.

Затем существует триплет на один дополнительный бит: setuid, setgid, липкий. Первые два заставляют (на исполняемом файле) программу быть выполненной как пользователь/группа, владеющий файлом (в зависимости от какого из двух битов установлены). Липкий бит является зависящим от реализации. Для исполняемых файлов это раньше означало, что код программы должен кэшироваться в подкачке для ускорения загрузки его в следующий раз. Для каталога это предотвращает непривилегированных пользователей, удаляющих файл, если они не владеют им, даже если они имели права сделать так иначе - это - то, почему это обычно устанавливается на мировых записываемых каталогах как /tmp.

В дополнение к этому много файловых систем поддерживают дополнительные списки управления доступом (ACL), которые позволяют более прекрасное гранулярное управление доступом. Они доступны с getfacl/setfacl вместо с chmod.

Как примечание стороны, подобная система разрешения обычно реализуется для памяти (RAM) с гранулярностью страницы. Основная цель состоит в том, чтобы придерживаться принципа "W^X": или можно записать в память, или можно выполнить ее, но не оба одновременно. В то время как обычно хорошая идея, это не работает на интерпретируемый своевременный скомпилированный код - например, Java, потому что интерпретатор должен компилировать/оптимизировать сгенерированный код (т.е. записать страницу) и затем выполнить его, часто инкрементно (и изменение полномочий, каждый раз не имел бы большого смысла).

3
28.01.2020, 02:28
  • 1
    Отметьте это chmod/ls используются для обработки ZFS acls на Солярисе, нет setfacl/getfacl. положительная сторона –  jlliagre 07.12.2012, 16:26

Теги

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