I thought this would be similar to LUKS with pam_mount
using one home partition for all users (I don't know if that can be done or would be a good idea using LUKS) or using separate partitions for each user, which in case of LUKS would be more cumbersome. Reading the FAQ having both users being logged in sould be sufficient, or so it seems:
Once one user can access an eCryptfs file, any users with permission
can also access the file. Should not eCryptfs require all users to
have the key in order to access the files?
eCryptfs deliberately makes no attempt to re-implement the
discretionary and mandatory access control mechanisms already present
in the Linux kernel. eCryptfs will simply require that a File
Encryption Key (FEK) be associated with any given inode in order to
decrypt the contents of the file on disk. This prevents an attacker
from accessing the file contents outside the context of the trusted
host environment; for instance, by removing the storage device or by
booting a live CD. This is the only type of unauthorized access that
eCryptfs is intended to prevent.
Once eCryptfs has associated that FEK with the inode, it does not
impose any additional restrictions on who or what can access the
files, deferring to the standard user/group/other permissions,
capabilities, SE Linux type enforcement, and so forth to regulate
access to the files. eCryptfs maintains no pedigree regarding how the
FEK found its way to the inode, so it has no way of knowing that any
particular UID should or should not be able to open the file, nor
should eCryptfs do such a thing.
Having eCryptfs impose additional access control onto the decrypted
file contents in a trusted host environment would provide no
additional security while introducing unintended usability issues. For
instance, a user may wish to share his decrypted files with certain
other users on the system without having to share his key with them or
add their keys to a set of keys wrapping the inode's FEK. Users expect
to be able to accomplish such a task via users, groups, capabilities,
and types, and eCryptfs defers access control decisions on trusted
host environments to these existing access control mechanisms.
You can find the complete FAQ in /usr/share/doc/ecryptfs-utils/ecryptfs-faq.html
or online.
Another workaround would be to use an eCrypfs folder outside the users home folders that can be shared and that has a single password that the users can share (working around that both users would have to log into their accounts).