mount.ecryptfs_private needs elevated privileges to mount() the user's encrypted "private" folder (e.g. the one that was set up by ecryptfs-setup-private). There are two ways to do that:
a) Have mount.ecryptfs_private marked with the suid bit and owned by root so that it always runs as root (that introduces a security risk and portage will print a warning about it)
b) Use file system capabilities and mark mount.ecryptfs_private with cap_dac_read_search,cap_setgid,cap_setuid,cap_sys_admin+ep and not require the suid bit set (sys_admin to mount(), setuid/setgid because it sets its uid/gid to 0 internally and dac_read_search because normally the private directory -the mountpoint- is only accessible by the user -not by root, at least not without dac_read_search-).
Currently only the first option is available when enabling the suid USE flag, without it mount.ecryptfs_private won't work and the user won't know until he/she tries to use it. It would be much better to print a warning message to alert the user that by not using the suid flag he/she won't be able to use mount.ecryptfs_private. Also it would be much better if the ebuild supported the filecaps USE flag and made the second option available to the users.
Same problem and same fix : add setuid on mount.ecryptfs_private.
The bug has been referenced in the following commit(s):
Author: Aaron Bauman <firstname.lastname@example.org>
AuthorDate: 2020-08-02 22:49:23 +0000
Commit: Aaron Bauman <email@example.com>
CommitDate: 2020-08-02 22:51:26 +0000
package.mask: last-rite sys-fs/ecryptfs-utils
Signed-off-by: Aaron Bauman <firstname.lastname@example.org>
profiles/package.mask | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
Upstream seems dead unfortunately. I've fixed all of the bugs I can though.
Also added an upstream bug reference here.