У меня есть дерево NFS, экспортированное с файлового сервера, который защищен с помощью Kerberos и использует LDAP для аутентификации и управления uid / gid. Все работает плавно для каждой клиентской машины и каждого отдельного пользователя, но я не уверен, как предоставить доступ к частям общего ресурса демонам.
Демоны обычно запускаются с setuid для локальной системной учетной записи, поэтому на сервере для них нет каких-либо конкретных учетных данных. Если я могу залезть и возиться с источником, я обычно могу заставить их вызвать kinit с файлом keytab для пользователя, который существует в kerberos, когда они запускаются, но это не всегда возможно.
Наша среда не позволяет мне взламывать вещи, делая их доступными для чтения, или полностью удалять Kerberos из NFS.
Я возился с добавлением поддерева в /etc/exports с участием all_squash, anonuid=... и anongid=... установлен, но это сделало его доступным для чтения на любой клиентской машине. Он должен быть доступен только для определенной машины.
Я пробовал использовать samba, но у нас есть несколько демонов, которые используют подход «NFS or bust» для работы с общими ресурсами (например, все, что связано с mercurial).
Большинство наших серверов работают под управлением Ubuntu 10.04 LTS, хотя проблема также затрагивает имеющийся у нас клиент 12.04 LTS.
Есть ли способ предоставить всей системе общесистемный билет для определенного пользователя Kerberos, чтобы любой пользователь этой системы всегда мог получить доступ к общему ресурсу? Или есть какой-нибудь другой метод достижения такого доступа, который я могу изучить?
«Правильный» способ сделать это - переписать сценарии инициализации, чтобы использовать k5start в режиме демона и на вкладках для каждого демона. Это гарантирует, что запущенный демон будет иметь доступ к действительному кешу учетных данных во время его работы.
Скорее всего, вам понадобятся принципы стиля daemon / hostname.domain.tld. Их легче отслеживать, и для них легче управлять вкладками. Добавление ключа в keytab автоматически увеличивает номер версии ключа (KVNO) и рандомизирует «пароль» для этого принципала.
Если вы используете gssproxy, со стандартной конфигурацией nfs-client, например:
[service/nfs-client]
mechs = krb5
cred_store = keytab:/etc/krb5.keytab
cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U
cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab
cred_usage = initiate
allow_any_uid = yes
trusted = yes
euid = 0
Вы можете поместить keytab службы в /var/lib/gssproxy/clients/%UID%.keytab, и gssproxy создаст билеты за вас. Это может быть предпочтительнее использования k5start, потому что k5start может испортить переходы SELinux.