lkml.org 
[lkml]   [2008]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 5/5] eCryptfs: Filename Encryption: mount option
On Thu, Nov 06, 2008 at 02:13:04PM -0800, Andrew Morton wrote:
> On Tue, 4 Nov 2008 15:43:13 -0600
> Michael Halcrow <mhalcrow@us.ibm.com> wrote:
> > Enable mount-wide filename encryption by providing the Filename
> > Encryption Key (FNEK) signature as a mount option. Note that the
> > ecryptfs-utils userspace package versions 61 or later support this
> > option.
>
> A usage example would, as always, be useful here.

When mounting with ecryptfs-utils version 61 or later, the mount
helper will detect the availability of the passphrase-based filename
encryption in the kernel (via the eCryptfs sysfs handle) and query the
user interactively as to whether or not he wants to enable the feature
for the mount. If the user enables filename encryption, the mount
helper will then prompt for the FNEK signature that the user wishes to
use, suggesting by default the signature for the mount passphrase that
the user has already entered for encrypting the file contents.

When not using the mount helper, the user can specify the signature
for the passphrase key with the ecryptfs_fnek_sig= mount option. This
key must be available in the user's keyring. The mount helper usually
takes care of this step. If, however, the user is not mounting with
the mount helper, then he will need to enter the passphrase key into
his keyring with some other utility prior to mounting, such as
ecryptfs-manager.

> Do we actually provide a secure key on the command line? If so, do
> any special steps need to be taken to prevent unauthorised viewing
> of it? Fancy things like `cat /proc/mounts' :)

The mount helper does things correctly by default. Never at any time
does anything provide an actual secret value to eCryptfs as a mount
parameter.


\
 
 \ /
  Last update: 2008-11-14 17:49    [W:0.044 / U:1.868 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site