Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 829576 - sys-fs/ecryptfs-utils has broken mount.ecryptfs
Summary: sys-fs/ecryptfs-utils has broken mount.ecryptfs
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: No maintainer - Look at if you want to take care of it
Keywords: NeedPatch
Depends on:
Reported: 2021-12-18 17:34 UTC by onkobu
Modified: 2021-12-19 18:27 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description onkobu 2021-12-18 17:34:16 UTC
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(?): This replaces setuid bit with capabilities.
Comment 1 Jonas Stein gentoo-dev 2021-12-19 00:07:04 UTC
please provide a complete minimal example, how to reproduce.
Comment 2 onkobu 2021-12-19 18:27:27 UTC
(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.