SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I do mount a directory for a second user like this:
Code:
mount -t ecryptfs /home/user2/.Private/ /home/user2/ -o ecryptfs_cipher=aes,ecryptfs_key_bytes=16,key=passphrase,ecryptfs_fnek_sig=1234567890abcdef,ecryptfs_unlink_sigs,ecryptfs_passthrough=no
It worked well this way until I upgraded to kernel 4.4.14. The mount itself works, but I can't access the directory any more.
dmesg output:
Code:
[ 53.924289] Error opening lower file for lower_dentry [0xeb8a9080] and lower_mnt [0xf08bb0d0]; rc = [-124]
[ 53.924294] ecryptfs_open: Error attempting to initialize the lower file for the dentry with name [/]; rc = [-124]
Apparently there were some changes to ecryptfs in 4.4.14. The Announcement from GKH says:
Quote:
Jann Horn (3):
ecryptfs: forbid opening files without mmap handler
Patch to ecryptfs see below. I am not a kernel or C programmer, so I can't tell what went wrong.
Do I need to change something to my mount command or is this a bug?
Did some more testing - decrypted and encrypted the users home directory again with kernel 4.4.14 and the tool ecryptfs-migrate-home. Used ecryptfs-mount-private as the user. The mount itself works. The directory is still not accessible.
However, I can access single files if I type the name (tab completition of bash doesn't work), e.g. 'cat /home/user/foo/bar' works, but 'ls /home/user/foo/ gives the error "Wrong medium type".
It really seems to be a bug. What is the best way to report it upstream?
I will test tomorrow, if this happens on other distros with kernel 4.4.14, where PAM is used, as well. Strange, that there are no other reports about this issue yet.
I confirmed, that this bug also appears on Arch Linux (which has PAM and systemd) using their provided linux-lts kernel 4.4.14. However, using the provided default kernel on Arch, which is 4.6.3 and has the same patch to ecryptfs applied as 4.4.14, the error doesn't occur and one can access an ecryptfs mounted directory perfectly normal.
So it seems, that kernel 4.4.14, and perhaps other still maintained LTS kernels where this patch was applied (4.1.27, 3.18.36, 3.14.73) are affected. As for kernel 3.10.x - which is the default kernel in Slackware 14.1 - I can't find the ecryptfs related entry in the changelog of the latest release 3.10.102.
Meanwhile it was stated at the ecryptfs mailing list, that the backported version of the patch needs to be adjusted. So, stay tuned for kernel 4.4.15.
Since I'd rather release Slackware 14.2 with a completely vanilla kernel (and 4.4.15 doesn't seem to be coming soon), I've put the proposed upstream patch for this issue in source/k/, and built packages in /testing/packages containing a fixed ecryptfs kernel module.
Since I'd rather release Slackware 14.2 with a completely vanilla kernel (and 4.4.15 doesn't seem to be coming soon), I've put the proposed upstream patch for this issue in source/k/, and built packages in /testing/packages containing a fixed ecryptfs kernel module.
Sorry, but it didn't work for me. I installed kernel-module-ecryptfs-4.4.14-x86_64-1.txz, even rebooted, but still getting the error "wrong medium type".
Three possibilities:
* I am doing something wrong
* The module in the package still isn't patched
* The patch doesn't work
I will rebuild the whole kernel with the patch applied to see if the patch does work at all.
Rebuilt the kernel on 64bit with the patch applied. Still "wrong medium type" error when accessing directories. It seems that the patch did not work as expected.
Confirmed - the patch at source/k/linux-4.4.14.ecryptfs.regression.diff is malformed, therefore it doesn't work.
Correct patch is attached. With this, ecryptfs works as expected again.
Confirmed - the patch at source/k/linux-4.4.14.ecryptfs.regression.diff is malformed, therefore it doesn't work.
Correct patch is attached. With this, ecryptfs works as expected again.
You might want to mark this thread as solved so others can benefit from your solution.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.