Summary: | sys-fs/ecryptfs-utils has broken mount.ecryptfs | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | onkobu |
Component: | Current packages | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | jstein |
Priority: | Normal | Keywords: | NeedPatch |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
onkobu
2021-12-18 17:34:16 UTC
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 |