Как смонтировать eCryptfs каталог на доступе самбы?
Среда
Я выполняю сервер Ubuntu 16.04 с eCryptfs и самбой.
Пользовательский боб создал зашифрованную частную папку через ecryptfs-setup-private. Переносящийся пароль соответствует паролю входа в систему Linux. Когда подключения боба через SSH, его частная папка дешифрована автоматически. Пользовательский боб имеет доступ самбы к его корневому каталогу. Учетные данные самбы соответствуют данным для входа в систему Linux.
Конфигурация PAM содержит записи по умолчанию (созданный Ubuntu и eCryptfs). /etc/fstab не содержит записей, характерных для eCryptfs.
Проблема
Когда боб получает доступ к его частной папке через самбу от клиента Windows, его частная папка не дешифрована. Журнал сервера самбы (/var/log/samba/some-client.log) содержит
Signature not found in user keyring
Perhaps try the interactive 'ecryptfs-mount-private'
Дальнейшее расследование
То же сообщение происходит, когда боб открывает оболочку через sudo; не происходит, когда боб открывает оболочку через su. По-видимому, брелок для ключей сеанса пользователя имеет другое содержание в зависимости от метода входа в систему:
$ su -c 'keyctl show @s' bob
Keyring
887339582 --alswrv 1000 65534 keyring: _uid_ses.1000
797923857 --alswrv 1000 65534 \_ keyring: _uid.1000
523913245 --alswrv 1000 1000 \_ user: 363f394f32249cc4
840141489 --alswrv 1000 1000 \_ user: 905f555cf7fd10e0
$ sudo -i -H -u bob -- keyctl show @s
Signature not found in user keyring
Perhaps try the interactive 'ecryptfs-mount-private'
Keyring
887339582 --alswrv 1000 65534 keyring: _uid_ses.1000
797923857 --alswrv 1000 65534 \_ keyring: _uid.1000
Кажется, что данные для входа в систему отсутствуют в брелоке для ключей при использовании sudo.
Я предполагаю это, когда я нахожу решение для sudo случай, это может быть применено к проблеме самбы.
Я пытался измениться /etc/pam.d/sudo к содержанию /etc/pam.d/su, но это не имело никакого эффекта. Я читал о ecryptfs-add-passphrase и pam_cifscreds, но не знайте, если и как один из них мог быть полезным здесь. Я просмотрел wikis ubuntuusers.de и Дуги Linux, нашли несколько вопросов на StackOverflow, и unix.stackexchange.com (ссылки опущены из-за низкой репутации), но еще не нашел решение.
- Что необходимо, чтобы eCryptfs использовал данные для входа в систему в
sudoслучай? - Что необходимо, чтобы eCryptfs использовал данные для входа в систему в случае самбы?
2 ответа
После дальнейших расследований я могу ответить на вопрос один: это не возможно для использования sudo или учетные данные самбы для автоматического дешифрования eCryptfs частной папки на входе в систему, потому что пароль неизвестен в любом случае.
1.) sudo
Позволяют нам предположить что пользователь alice вызовы sudo -u bob. Alice не нужен пароль Bob's для этого; она использует свой собственный пароль. Таким образом Bob's пароль не известен и не может добавляться к пользовательскому брелоку для ключей или использоваться eCryptfs. Вот в чем разница к su, который требует пароля боба. Поэтому возможно автосмонтировать eCryptfs папку с su, но не с sudo.
2.) Samba
Мое наблюдение состояло в том, что данные для входа в систему отсутствуют в брелоке для ключей сеанса пользователя. Я думал, что, возможно, самба не добавляет их по умолчанию, таким образом, я искал способ сделать это вручную.
После определенного исследования я нашел модуль PAM pam_cifscreds, который может использоваться для обеспечения, удостоверения пользователя к ядру - звучит хорошим. Я добавил pam_cifscreds.so к обоим средствам PAM auth (для хранения пароля в брелоке для ключей) и session, но не имел никакой удачи. С debug набор аргумента, эти session вызов записал сообщение no stored password found в журнал; эти auth вызов не был видим.
Дальнейшее исследование приводит меня к другому модулю PAM pam_script и его файл logscript в качестве примера, который может использоваться для трассировки вызовов PAM. Это показало, что session средство называют на каждом клиентском подключении самбы, но auth средство не. Затем я нашел этот абзац в smb.conf Конфигурация PAM :
Samba всегда игнорирует PAM для аутентификации в случае, шифруют пароли = да. Причина состоит в том, что модули PAM не могут поддерживать механизм аутентификации с запросом и подтверждением, необходимый в присутствии шифрования пароля SMB.
В наше время, клиент самбы не отправляет пароль в виде открытого текста, но значение хэш-функции к серверу. Таким образом сервер не имеет никакого доступа к паролю и не может добавить его к брелоку для ключей.
, вероятно, возможно изменить конфигурацию самбы для разрешения паролей в виде открытого текста, но я не хочу это и таким образом не попробовал его.
Заключение
Моя идея прозрачного дешифрования серверной стороны на основе данных для входа в систему самбы не возможна, потому что пароль отсутствует на сервере.
может быть другая опция как обходное решение: если бы eCryptfs не использовал сингл wrapped-passphrase файл, но один на тип входа в систему (например, пароль UNIX, Samba, сертификат SSH...), то монтирующийся пароль мог быть развернут в зависимости от входа в систему. Но как реализовывающий эту идею кажется довольно сложным и трудоемким для меня, я не отслежу ее далее.
Это - давнишняя ошибка
https://bugs.launchpad.net/ecryptfs / + ошибка/277578
, ecryptfs не работает правильно по nfs, cifs, самбе, WebDAV, или обходное решение aufs
- использует sshfs: https://bugs.launchpad.net/ecryptfs / + bug/277578/comments/8
Другие опции: Зарегистрируйте ре отчета об ошибках: sudo / su, если Вы желаете.