On Tue, Apr 08, 2008 at 06:59:28AM -0400, jayjwa wrote:
> Kernel 2.6.24.4 patched with the patch from the ecryptfs-users
> mailing list.

I posted an updated patch yesterday that makes procfs the default
daemon communication mechanism:

http://downloads.sourceforge.net/ecryptfs/ecryptfs-procfs-kernel-20080407.txt

From here on out, the netlink interface should be treated like the
Bubonic plague.

I made release 43, which really actually fixes the TPM key module; I
let a reversal of the fix slip in there somehow.

> Select key type to use for newly created files:
>   1) openssl
>   2) passphrase
> Selection: 1
> PEM key file [/root/.ecryptfs/pki/openssl/key.pem]:
> 
>                                                     ^^^^^^^^^^^^^^
> 
> (Cannot enter key here, or rather chars are not echoed back to the tty.
>   Very hard to tell what one is entering, unless you copy/paste
> it. )

Just had to set a flag in the decision graph node for this input
value. Fixed in release 43.

> As a side question, does #1, connector, work?

No. I should remove any mention of anything other than netlink and
procfs in that module parameter descriptor.

> Thoughts, Issues:
> 
> 1) When entering the public key, typing doesn't echo the characters.
>     Telling if you typed correctly is differicult.

Fixed in the latest release.

> 2) A user can read ecryptfs files even if he has no/wrong key, as long
>     as ecryptfs has been mounted successfully. Shouldn't only users with
>     a proper key be able to read the files?

I added a new FAQ entry for this:

http://ecryptfs.sourceforge.net/ecryptfs-faq.html#daemon-crash

I am open to debate on this issue, but I really see any alternatives
creating more problems than solutions.

> 3) What's in modprobe.conf always overrules what you enter on the command
>     line, even if the parm. doesn't exist in modprobe.conf (but only on the
>     command line). In this case, you'll likely get a crash/hang.

procfs is now the default in both the latest kernel patch and in the
userspace tools, so this should be less of a problem. Avoid using
netlink at all, or your inodes will spontaneously transform into Token
Ring frames and your video card will spout six-inch flames. I will
probably just yank that netlink interface code entirely when I send
the procfs interface code upstream.

> 4) There were a few error messages in syslog:
> 
>   mount.ecryptfs: Error initializing key module 
> [/usr/lib/ecryptfs/libecryptfs_key_mod_gpg.so]; rc = [-22]
>   ecryptfsd: Error initializing key module 
> [/usr/lib/ecryptfs/libecryptfs_key_mod_gpg.so]; rc = [-22]
>   kernel: Error attempting to read the [user.ecryptfs] xattr from
> the lower file; return value = [4294967201]

The gnupg key module code is just there as a placeholder for now. The
user.ecryptfs xattr error message is probably spurious, and I should
just remove it.

Thanks,
Mike

Attachment: pgpSY7itpZ11k.pgp
Description: PGP signature

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Register now and save $200. Hurry, offer ends at 11:59 p.m., 
Monday, April 7! Use priority code J8TLD2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
eCryptfs-users mailing list
eCryptfs-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecryptfs-users

Reply via email to