Dustin, I realize those patches are not in finished form, but it looks like the changes to ecryptfs_add_auth_tok_to_keyring() will cause a regression in the case of non-pam initiated eCryptfs mounts. I don't think we want auth toks for those types of mounts to be specific to any session. Also, the keyring variable should technically be of type key_serial_t.
Do you know what is going on in ecryptfs_validate_keyring() when KEY_SPEC_SESSION_KEYRING is being linked to KEY_SPEC_USER_KEYRING? Isn't that essentially the same thing as what your patch is doing with the first call to add_key() in ecryptfs_add_auth_tok_to_keyring()? -- umount of ecryptfs does not automatically clear the keyring (can be mounted by root later) https://bugs.launchpad.net/bugs/313812 You received this bug notification because you are a member of eCryptfs, which is subscribed to ecryptfs-utils in ubuntu. Status in eCryptfs - Enterprise Cryptographic Filesystem: Triaged Status in “ecryptfs-utils” package in Ubuntu: Fix Released Status in “ecryptfs-utils” package in Fedora: Fix Released Bug description: How to reproduce : 1) setup a private directory 2) sudo -s cd / mkdir source mkdir target cp ~user/.Private/example.pdf source file /source/example.pdf /source/example.pdf: data mount -t ecryptfs source target Passphrase: type anything that is not your passphrase or passwords Select cipher: 1) aes: blocksize = 16; min keysize = 16; max keysize = 32 (loaded) 2) blowfish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded) 3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24 (not loaded) 4) twofish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded) 5) cast6: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded) 6) cast5: blocksize = 8; min keysize = 5; max keysize = 16 (not loaded) Selection [aes]: Select key bytes: 1) 16 2) 32 3) 24 Selection [16]: Enable plaintext passthrough (y/n) [n]: n Attempting to mount with the following options: ecryptfs_key_bytes=16 ecryptfs_cipher=aes ecryptfs_sig=4c748f746abcc24e WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt], it looks like you have never mounted with this key before. This could mean that you have typed your passphrase wrong. Would you like to proceed with the mount (yes/no)? yes Would you like to append sig [4c748f746abcc24e] to [/root/.ecryptfs/sig-cache.txt] in order to avoid this warning in the future (yes/no)? no Not adding sig to user sig cache file; continuing with mount. Mounted eCryptfs file /source/example.pdf /source/example.pdf: PDF document, version 1.4 Now I know that the files are really encrypted (using a wrong passphrase on files copied to another computer makes the file unreadable), but I don't understand how root on my system can mount my files without the correct passphrase... is the passphrase stored somewhere? This is really strange and doesn't give me too much confidence in this technology. Let's hope I overlooked something. _______________________________________________ Mailing list: https://launchpad.net/~ecryptfs Post to : [email protected] Unsubscribe : https://launchpad.net/~ecryptfs More help : https://help.launchpad.net/ListHelp
