271
260
<p><h3>Q. On what filesystems can I expect eCryptfs to function?</h3></p>
274
eCryptfs has been well tested on EXT3, and it should work well on
275
other popular local filesystems such as JFS, XFS, ReiserFS, and so
263
eCryptfs has been well tested on EXT3, EXT4, XFS and it should work well on
264
other popular local filesystems such as JFS, ReiserFS, and so
276
265
forth. Changes in the 2.6.24 kernel make eCryptfs more functional on
277
266
NFS and CIFS, although there is still a little more work to do in
278
267
order to make eCryptfs function as well on networked filesystems as it
279
currently works on local filesystems. There is a <a
280
href="http://downloads.sourceforge.net/ecryptfs/ecryptfs-fix-nfs.txt">patch</a>
281
to help resolve an unlink bug with eCryptfs on NFS; this patch will
282
eventually make it upstream once it is well tested.
268
currently works on local filesystems. This <a
269
href="https://bugs.launchpad.net/ecryptfs/+bug/277578">bug</a>
270
tracks the issues around making eCryptfs work on top of NFS, CIFS, Samba
297
286
configuration will lead to a kernel process stack overflow.
302
<p><h3>Q. Can I mount eCryptfs with a public key?</h3></p>
305
You can mount eCryptfs with a public key if you have public key
306
support (<code>pubkey</code>) in your kernel. You first need to
307
generate a public/private keypair. Run <code>ecryptfs-manager</code>,
308
follow the prompts to generate the keypair for the key module of your
309
choosing, start the <code>ecryptfsd</code> daemon, and then specify
310
the key module when mounting. For instance, for the OpenSSL key
311
module, assuming you created your key in
312
<code>/usb-drive/mykey.pem</code> and you want to do a layover mount
313
on <code>/secret</code>, run:
319
# mount -t ecryptfs -o key=openssl:keyfile=/usb-drive/mykey.pem /secret /secret
323
<a name="pubkey-about">
325
<p><h3>Q. Why would I want to use public key anyway?</h3></p>
328
Cryptographic keys derived from passphrases are generally
329
worthless. Most passphrases that people can reasonably remember lack
330
even the strength of a 64-bit symmetric key. The idea behind using a
331
public key is to provide an opportunity for two-factor authentication;
332
for instance, with OpenSSL RSA, the PEM file is ``something you have''
333
and the passphrase is ``something you know.'' This works best if you
334
store your public key and your encrypted files on separate media.
338
The ``public key'' mode of operation in eCryptfs is actually more
339
general than public key. It allows for arbitrary key modules to
340
perform the File Encryption Key (FEK) encryption and decryption. The
341
key module could do RSA. Or, it could retrieve an employee's key from
342
a Domino server. Or, it could unseal the key protected by a Trusted
343
Computing chip, which will only honor the unseal request if the
344
machine is booted into a trusted state.
348
A key module now ships in ecryptfs-utils to interface with
349
cryptographic tokens via PKCS#11. There is also a key module to
350
interface with a TPM chip.
355
<p><h3>Q. What is <code>ecryptfsd</code>?</h3></p>
358
<code>ecryptfsd</code> is a daemon that runs as the user performing
359
file operations under the eCryptfs mount point. It manages public key
360
operations in userspace on file open events. <code>ecryptfsd</code>
361
only needs to be run when a mount is done with a public key module.
364
<a name="ecryptfs-manager">
366
<p><h3>Q. What is <code>ecryptfs-manager</code>?</h3></p>
369
<code>ecryptfs-manager</code> is an application that manages eCryptfs
370
objects such as keys. You can use <code>ecryptfs-manager</code> to ask
371
key modules to generate new keys for you, for instance.
374
289
<a name="nonroot">
376
291
<p><h3>Q. Do I have to be root to mount eCryptfs?</h3></p>
379
eCryptfs mounts can be set up to be done by non-root users. Generally,
380
you want to perform the initial key generation and mount as the root
381
user. Then, you can do a mount as a user by putting the appropriate
382
options in /etc/fstab, adding the keys to the user session keyring
383
(using ecryptfs-manager), and performing the mount in such a way that
384
bypasses the mount helper. This is not very well automated in the
385
current release, but it is possible right now with some manual
386
steps. The instructions on using the PAM module are contained in the
387
README and give the steps necessary to set that up; just follow all
388
the directions except the last PAM step to see how it works:
393
href="http://ecryptfs.sourceforge.net/README">http://ecryptfs.sourceforge.net/README</a>
396
In short, you will want something like this in your fstab:
400
/home/user/secret /home/user/secret ecryptfs
401
rw,ecryptfs_sig=deadbeefbaadf00d,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,user,noauto 0 0
406
You need to get the corresponding authentication token for the
407
ecryptfs_sig into your user session keyring;
408
<code>ecryptfs-manager</code> and the PAM module can both do this for
409
you. Alternatively, you can write your own application that calls
410
<code>ecryptfs_add_passphrase_key_to_keyring()</code> or
411
<code>ecryptfs_add_key_module_key_to_keyring()</code> in
412
<code>libecryptfs.so</code>. Then you will want to mount with the -i
413
option to prevent the mount helper from being called.
294
eCryptfs mounts can be set up to be done by non-root users, using
295
the <code>ecryptfs-setup-private</code> utility. The root user
296
can also setup mount points in <code>/etc/fstab</code>, but the
297
non-root users will need to manually load their keys into the
441
326
stored in the extended attribute regions of the lower files.
444
<a name="filename-enc">
446
<p><h3>Q. What about filename encryption?</h3></p>
449
The namespace problem arises when we consider the case where two files
450
have the same unencrypted name. This can be a problem when the user
451
does not have the key for every file in any given directory. Imagine,
452
for instance, that Alice creates a file named ``meeting_notes.txt'' in
453
a shared directory on an NFS server. The filename is encrypted with a
454
key known only to Alice and Carol. Bob then creates a file in the same
455
shared NFS directory and also names it ``meeting_notes.txt'',
456
encrypting the filename with another key only known to Bob and
457
Carol. Bob's eCryptfs client cannot detect the unencrypted filename
458
conflict in the namespace because Bob does not have Alice's key.
462
So two different files that have the same unencrypted name and
463
different encrypted names appear in the same directory. When Carol,
464
who has both Alice's key and Bob's key, lists the contents of the
465
directory, he winds up seeing two different files with the same
466
filename in the same directory, which is a POSIX violation.
470
The solution we may implement is to use a separate key just for
471
filename encryption, requiring all filenames encrypted under any given
472
directory to be encrypted with that key. Filename encryption is a
473
planned feature, but there is currently no set date for when it will
477
329
<a name="sparse">
479
331
<p><h3>Q. What about sparse files?</h3></p>
707
<a name="daemon-crash">
709
<p><h3>Why does the eCryptfs daemon crash my kernel?</h3></p>
712
You are probably using a kernel with the netlink interface to the
713
userspace daemon. The netlink interface with the userspace daemon is
718
To resolve the issue, there is a <a
719
href="http://downloads.sourceforge.net/ecryptfs/ecryptfs-miscdev-kernel-20080415-0.txt">patch</a>
720
to migrate eCryptfs from using netlink for kernel-daemon
721
communications to using a device handle instead. This patch has been
722
merged into the -mm tree, and we anticipate that this patch will find
723
its way into kernel release 2.6.26. In addition to this patch, you
724
will need ecryptfs-utils release 44 or greater.
727
559
<a name="no-ecryptfsac">
729
561
<p><h3>Once one user can access an eCryptfs file, any users with
added
removed
doc/ecryptfs-faq.html
