Это /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
Владение и права доступа в основном сотрудничают. Ownership говорит систему, кто может получить доступ к файлу, в полномочиях файла говорится как.
Владение разделяет доступ на три группы: пользователь (отдельный пользователь, владеющий файлом), группа (пользователей), другие (остальная часть мира).
Полномочия: r
- чтение позволяется, w
- запись позволяется, x
- выполнение позволяется
Для каталогов значение немного отличается: x
позволяет Вам вводить каталог, в то время как r
список его содержания (и w
позволяет Вам обновить его) - который означает, что, если Вы знаете точное имя файла, Вы не должны читать полномочия на каталоге, это находится в, x
достаточно. Вам нужно r
на файле все же.
Затем существует триплет на один дополнительный бит: setuid, setgid, липкий. Первые два заставляют (на исполняемом файле) программу быть выполненной как пользователь/группа, владеющий файлом (в зависимости от какого из двух битов установлены). Липкий бит является зависящим от реализации. Для исполняемых файлов это раньше означало, что код программы должен кэшироваться в подкачке для ускорения загрузки его в следующий раз. Для каталога это предотвращает непривилегированных пользователей, удаляющих файл, если они не владеют им, даже если они имели права сделать так иначе - это - то, почему это обычно устанавливается на мировых записываемых каталогах как /tmp
.
В дополнение к этому много файловых систем поддерживают дополнительные списки управления доступом (ACL), которые позволяют более прекрасное гранулярное управление доступом. Они доступны с getfacl
/setfacl
вместо с chmod
.
Как примечание стороны, подобная система разрешения обычно реализуется для памяти (RAM) с гранулярностью страницы. Основная цель состоит в том, чтобы придерживаться принципа "W^X": или можно записать в память, или можно выполнить ее, но не оба одновременно. В то время как обычно хорошая идея, это не работает на интерпретируемый своевременный скомпилированный код - например, Java, потому что интерпретатор должен компилировать/оптимизировать сгенерированный код (т.е. записать страницу) и затем выполнить его, часто инкрементно (и изменение полномочий, каждый раз не имел бы большого смысла).
chmod/ls
используются для обработки ZFS acls на Солярисе, нетsetfacl/getfacl
. положительная сторона – jlliagre 07.12.2012, 16:26