When using command mount.ecryptfs as suggested in some articles from different sources it always bails out with Exiting. Unable to obtain passwd info From the sources it can easily be seen that mlockall comes first followed by getpwuid. This has to be the other way around. It also seems as if edits were skipped. Parameter count must be exactly 3 while some articles suggest 2 or 3. Two would be sufficient when defaults are acceptable 3 or more add additional options. Reproducible: Always Steps to Reproduce: 1. invoke mount.ecryptfs bim bom Actual Results: Exiting. Unable to obtain passwd info Expected Results: Mounts bim to bom or fails with file not found (passwd-failure is before file system checks so neither bim nor bom need to exist) The code from mount.ecryptfs_private looks totally different. Whereas I'd expect that mount private is a special case of the general mount. Fixing this requires actions upstream or a hard fork. I can't do this immediately nor fast but basically it is doable in finite time. (Two people would reduce the bus factor.) Would also make sense to incorporate the suggestions from 2009(?): https://bugs.launchpad.net/ecryptfs/+bug/366140/comments/3 This replaces setuid bit with capabilities.
please provide a complete minimal example, how to reproduce.
(In reply to Jonas Stein from comment #1) > please provide a complete minimal example, how to reproduce. Just invoke the following command on command line: mount.ecryptfs bim bom As written before it is not necessary that bim or bom exist at all. mount.ecryptfs bails out way before (and also option count of 2 is less than required 3). Regular mount -t ecryptfs or mount.ecryptfs_private work flawlessly. I created the bug as a minor to track this when I return to it some day. Locally I already edited the code (mount.ecryptfs.c, no patches applied) to output the (correct) UID and invoke getpwuid before mlockall. Then it also enters interactive mode. I also dug into the details of Kernel keyring operations and enhanced the wiki page[1]. (After doing some tests with different ciphers, key sizes and remote file systems.) With the current state of the project (at launchpad) in mind and potential issues with suid bit I'd say patching is not enough. [1] https://wiki.gentoo.org/wiki/ECryptfs