Private directory is not mounted on login via samba or sudo shell

Bug #1711790 reported by Christian on 2017-08-19
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

I created an encrypted private folder via 'ecryptfs-setup-private' on an Ubuntu server 16.04. The wrapping passphrase matches the linux login passphrase. When I connect via SSH, my private folder is decrypted automatically. I have samba access to my home directory. The samba credentials match the linux login credentials. The PAM configuration contains the default entries (created by Ubuntu and eCryptfs).

Problem: When I access my private folder via samba from a Windows client, the private folder is not decrypted. The samba server log (/var/log/samba/some-client.log) contains
Signature not found in user keyring
Perhaps try the interactive 'ecryptfs-mount-private'
The same message occurs when I open a shell via 'sudo -i -H -u'; it does not occur when I open a shell via 'su'. It seems that the login credentials are missing in the keyring when using samba or a sudo shell.

I'm not really sure if this problem is actually a bug or a configuration issue. I tried changing /etc/pam.d/sudo to the contents of /etc/pam.d/su, but it had no effect. I've read about 'ecryptfs-add-passphrase' and 'pam_cifscreds', but don't know if and how one of these could be helpful here.

Please see for further details.

Jason Xing (wlxing) wrote :

If I remember correctly, you have to mount the directory after setting up the private folders. So there are two methods to mount folders 1)interactive-mount (#ecryptfs-mount-private) 2) #sudo mount -t ecryptfs [encrypted_folder] [decrypted_folder]. Does it make sense?

Christian (ubuntu-linux-user) wrote :

Thanks for your answer. The second option ('mount' call) is normally executed by eCryptfs automatically on login.

Christian (ubuntu-linux-user) wrote :

The observed sitution is not a bug but expected behaviour.

Nowadays, a samba client does not send the clear-text password but a hash value to the server. Thus, the server has no access to the password and cannot add it to the keyring.

The same applies to the sudo case: a 'sudo' caller uses his own password, not the one of the target user. Therefore the password is not known and cannot be added to the keyring. That's a difference to `su` which requires the password of the target user.

More detailed explanations can be found as answer to the question posted above.

Christian (ubuntu-linux-user) wrote :

Possible workaround: if eCryptfs didn't use a single 'wrapped-passphrase' file but one per login type (e.g. UNIX password, Samba, SSH certificate, ...), the mounting passphrase could be unwrapped depending on the login.

Changed in ecryptfs:
status: New → Opinion
Jason Xing (wlxing) wrote :

It seems that I got what you mean. I'm going to reproduce it and then get back some useful information to you. Thanks for your bug report:)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers