Please patch key_mod.c

Please patch key_mod.c

[Jaroslav Fojtik]

[-- Attachment #1: Mail message body --]
[-- Type: text/plain, Size: 1579 bytes --]

Dears,

Please patch key_mod.c.

If you receive following message, it is totally frustrating because you do not know which
directory attempted to open. The path at least gives some info about it.

======================================================================================

mount.ecryptfs /DATA/.BACKUP /DATA/BACKUP -o 
key=passphrase,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_passthrough=no,ecryptfs_
enable_filename_crypto=yes,ecryptfs_fnek_sig=87f8f52c6f46cfca
Error attempting to evaluate mount options: [-1] Operation not permitted
Check your system logs for details on why this happened.
Try updating your ecryptfs-utils package, and/or
submit a bug report on https://bugs.launchpad.net/ecryptfs

2 keys in keyring:
620524981: --alswrv     0     0 user: 87f8f52C6f46cfcA
1017206571: --alswrv     0     0 user: 87f8f52c6f46cfca

Mar 30 18:40:39 ESC_router mount.ecryptfs: ERROR: Could not open key_mod directory 
Mar 30 18:40:39 ESC_router mount.ecryptfs: Error attempting to get key module list; rc = 
[-1] 


best regards
   Jara

---------------------------------------------------

*** key_mod.c.old	Sat May 10 17:57:51 2014
--- key_mod.c	Sat May 10 17:58:31 2014
***************
*** 252,258 ****
  	}
  	if (!(dp = opendir(dir_name))) {
  		syslog(LOG_WARNING,
! 		       "ERROR: Could not open key_mod directory\n");
  		rc = -EPERM;
  		goto out;
  	}
--- 252,258 ----
  	}
  	if (!(dp = opendir(dir_name))) {
  		syslog(LOG_WARNING,
! 		       "ERROR: Could not open key_mod directory [%s]\n", dir_name);
  		rc = -EPERM;
  		goto out;
  	}






[-- Attachment #2: key_mod.c.diff --]
[-- Type: Application/Octet-stream, Size: 463 bytes --]

*** key_mod.c.old	Sat May 10 17:57:51 2014
--- key_mod.c	Sat May 10 17:58:31 2014
***************
*** 252,258 ****
  	}
  	if (!(dp = opendir(dir_name))) {
  		syslog(LOG_WARNING,
! 		       "ERROR: Could not open key_mod directory\n");
  		rc = -EPERM;
  		goto out;
  	}
--- 252,258 ----
  	}
  	if (!(dp = opendir(dir_name))) {
  		syslog(LOG_WARNING,
! 		       "ERROR: Could not open key_mod directory [%s]\n", dir_name);
  		rc = -EPERM;
  		goto out;
  	}

Re: Please patch key_mod.c

[Tyler Hicks]

[-- Attachment #1: Type: text/plain, Size: 1933 bytes --]

Sorry for missing this patch, I've been traveling.

On 2014-05-10 19:33:17, Jaroslav Fojtik wrote:
> Dears,
> 
> Please patch key_mod.c.

This change looks good to me. I've pushed it to lp:ecryptfs. Thanks!

Tyler

> 
> If you receive following message, it is totally frustrating because you do not know which
> directory attempted to open. The path at least gives some info about it.
> 
> ======================================================================================
> 
> mount.ecryptfs /DATA/.BACKUP /DATA/BACKUP -o 
> key=passphrase,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_passthrough=no,ecryptfs_
> enable_filename_crypto=yes,ecryptfs_fnek_sig=87f8f52c6f46cfca
> Error attempting to evaluate mount options: [-1] Operation not permitted
> Check your system logs for details on why this happened.
> Try updating your ecryptfs-utils package, and/or
> submit a bug report on https://bugs.launchpad.net/ecryptfs
> 
> 2 keys in keyring:
> 620524981: --alswrv     0     0 user: 87f8f52C6f46cfcA
> 1017206571: --alswrv     0     0 user: 87f8f52c6f46cfca
> 
> Mar 30 18:40:39 ESC_router mount.ecryptfs: ERROR: Could not open key_mod directory 
> Mar 30 18:40:39 ESC_router mount.ecryptfs: Error attempting to get key module list; rc = 
> [-1] 
> 
> 
> best regards
>    Jara
> 
> ---------------------------------------------------
> 
> *** key_mod.c.old	Sat May 10 17:57:51 2014
> --- key_mod.c	Sat May 10 17:58:31 2014
> ***************
> *** 252,258 ****
>   	}
>   	if (!(dp = opendir(dir_name))) {
>   		syslog(LOG_WARNING,
> ! 		       "ERROR: Could not open key_mod directory\n");
>   		rc = -EPERM;
>   		goto out;
>   	}
> --- 252,258 ----
>   	}
>   	if (!(dp = opendir(dir_name))) {
>   		syslog(LOG_WARNING,
> ! 		       "ERROR: Could not open key_mod directory [%s]\n", dir_name);
>   		rc = -EPERM;
>   		goto out;
>   	}
> 
> 
> 
> 
> 



[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

kernel crash after enable ecryptfs under abnormal power off

[Hanks Wang]

Hi Tyler,

It happened kernel crash if we enable ecryptfs in kernel-space and mount 
ecryptfs in the user-space if we reboot device after the device is 
powered off abnormally, such as the device is pulled off power line. At 
the same time, if we normally power off the device and reboot it, it 
works well. I don't try this case on the computer device, it just 
happened on my own mobile device, because I want to use ecryptfs on the 
mobile area.

I also read your formal mail thread about kernel crash 
http://lkml.iu.edu/hypermail/linux/kernel/1203.1/03801.html, which seems 
to be crashed on the same line. Actually, I used the parameter of 
ecryptfs_passthrouth to enable plain test readable. Could you kindly 
give me some suggestion about how to quick debug or resolve this problem?



My method to mount ecryptfs file system is following:

mount -t ecryptfs ～/encrypt  ~/encrypt  -o ecryptfs_key_bytes=32 -o 
ecryptfs_cipher=aes -o no_sig_cache -o passphrase_passwd=%s -o 
ecryptfs_enable_filename_crypto=n  -o ecryptfs_passthrough -o key=passphrase


Detail crash information is:
--------------------------------------------------------------------------------------------------
[   87.924154] c3 kernel BUG at 
/home/abuild/rpmbuild/BUILD/kernel-pachira-3.4.5/kernel/fs/ecryptfs/crypto.c:464!
[   87.934258] c3 Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[   87.940376] c3 Modules linked in: ittiam mali(O) ump(O)
[   87.945661] c3 CPU: 3    Tainted: G           O  (3.4.5 #1)
[   87.951261] c3 PC is at ecryptfs_encrypt_page+0x34/0x390
[   87.956646] c3 LR is at ecryptfs_writepage+0x4c/0x9c
[   87.961623] c3 pc : [<c0202a4c>]    lr : [<c0201574>]    psr: 40070013
[   87.961635] c3 sp : c37d3c50  ip : c37d3ce0  fp : c37d3cdc
[   87.973668] c3 r10: 00000000  r9 : db6f1948  r8 : c0fb1874
[   87.979199] c3 r7 : c0fb1874  r6 : dc914840  r5 : dc914918  r4 : dc9149c4
[   87.985985] c3 r3 : 00000003  r2 : c37d3ce0  r1 : c37d3e40  r0 : c0fb1874
[   87.992836] c3 Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM 
Segment kernel
[   88.000477] c3 Control: 10c53c7d  Table: 9b6ec06a  DAC: 00000015
[   88.006497] c3
[   88.006503] c3 PC: 0xc02029cc:
[   88.011351] c3 29cc  e0614004 ea000003 e3560000 e0855004 15834008 
e3a04000 e2800001 e2833010
[   88.019773] c3 29ec  e1500007 a3a02000 b3a02001 e3540000 d3a02000 
e3520000 1affffd9 e3540000
[   88.028275] c3 2a0c  c3e0000b e89daff8 c0bea5d0 e1a0c00d e92ddff0 
e24cb004 e24dd064 e92d4000
......

[   89.134149] c3 [<c0202a4c>] (ecryptfs_encrypt_page+0x34/0x390) from 
[<c0201574>] (ecryptfs_writepage+0x4c/0x9c)
[   89.134173] c3 [<c0201574>] (ecryptfs_writepage+0x4c/0x9c) from 
[<c00e2a58>] (__writepage+0x24/0x48)
[   89.134195] c3 [<c00e2a58>] (__writepage+0x24/0x48) from [<c00e305c>] 
(write_cache_pages+0x2f4/0x404)
[   89.134215] c3 [<c00e305c>] (write_cache_pages+0x2f4/0x404) from 
[<c00e31bc>] (generic_writepages+0x50/0x6c)
[   89.134234] c3 [<c00e31bc>] (generic_writepages+0x50/0x6c) from 
[<c00e4934>] (do_writepages+0x3c/0x48)
[   89.134255] c3 [<c00e4934>] (do_writepages+0x3c/0x48) from 
[<c0143ca8>] (writeback_single_inode+0x1c4/0x40c)
[   89.134276] c3 [<c0143ca8>] (writeback_single_inode+0x1c4/0x40c) from 
[<c0144200>] (writeback_sb_inodes+0x15c/0x214)
[   89.134295] c3 [<c0144200>] (writeback_sb_inodes+0x15c/0x214) from 
[<c014432c>] (__writeback_inodes_wb+0x74/0xc0)
[   89.134315] c3 [<c014432c>] (__writeback_inodes_wb+0x74/0xc0) from 
[<c0144538>] (wb_writeback+0x1c0/0x364)
[   89.134333] c3 [<c0144538>] (wb_writeback+0x1c0/0x364) from 
[<c0144bd4>] (wb_do_writeback+0xf8/0x26c)
[   89.134352] c3 [<c0144bd4>] (wb_do_writeback+0xf8/0x26c) from 
[<c0144e34>] (bdi_writeback_thread+0xec/0x2e4)
[   89.134373] c3 [<c0144e34>] (bdi_writeback_thread+0xec/0x2e4) from 
[<c005f3d8>] (kthread+0x9c/0xa8)
[   89.134393] c3 [<c005f3d8>] (kthread+0x9c/0xa8) from [<c000ff54>] 
(kernel_thread_exit+0x0/0x8)
[   89.134408] c3 Code: e2864f61 e5963184 e3130004 1a000000 (e7f001f2)

Re: kernel crash after enable ecryptfs under abnormal power off

[Tyler Hicks]

[-- Attachment #1: Type: text/plain, Size: 5124 bytes --]

On 2014-06-10 22:13:22, Hanks Wang wrote:
> 
> Hi Tyler,
> 
> It happened kernel crash if we enable ecryptfs in kernel-space and
> mount ecryptfs in the user-space if we reboot device after the
> device is powered off abnormally, such as the device is pulled off
> power line. At the same time, if we normally power off the device
> and reboot it, it works well. I don't try this case on the computer
> device, it just happened on my own mobile device, because I want to
> use ecryptfs on the mobile area.
> 
> I also read your formal mail thread about kernel crash
> http://lkml.iu.edu/hypermail/linux/kernel/1203.1/03801.html, which
> seems to be crashed on the same line. Actually, I used the parameter
> of ecryptfs_passthrouth to enable plain test readable. Could you
> kindly give me some suggestion about how to quick debug or resolve
> this problem?

You don't want to enable ecryptfs_passthrough. That will treat the file
as a plaintext file and writes to the file won't be encrypted. I doubt
that's what you want.

> My method to mount ecryptfs file system is following:
> 
> mount -t ecryptfs ～/encrypt  ~/encrypt  -o ecryptfs_key_bytes=32 -o
> ecryptfs_cipher=aes -o no_sig_cache -o passphrase_passwd=%s -o
> ecryptfs_enable_filename_crypto=n  -o ecryptfs_passthrough -o
> key=passphrase
> 
> 
> Detail crash information is:
> --------------------------------------------------------------------------------------------------
> [   87.924154] c3 kernel BUG at /home/abuild/rpmbuild/BUILD/kernel-pachira-3.4.5/kernel/fs/ecryptfs/crypto.c:464!
> [   87.934258] c3 Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
> [   87.940376] c3 Modules linked in: ittiam mali(O) ump(O)
> [   87.945661] c3 CPU: 3    Tainted: G           O  (3.4.5 #1)
> [   87.951261] c3 PC is at ecryptfs_encrypt_page+0x34/0x390
> [   87.956646] c3 LR is at ecryptfs_writepage+0x4c/0x9c
> [   87.961623] c3 pc : [<c0202a4c>]    lr : [<c0201574>]    psr: 40070013
> [   87.961635] c3 sp : c37d3c50  ip : c37d3ce0  fp : c37d3cdc
> [   87.973668] c3 r10: 00000000  r9 : db6f1948  r8 : c0fb1874
> [   87.979199] c3 r7 : c0fb1874  r6 : dc914840  r5 : dc914918  r4 : dc9149c4
> [   87.985985] c3 r3 : 00000003  r2 : c37d3ce0  r1 : c37d3e40  r0 : c0fb1874
> [   87.992836] c3 Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA
> ARM Segment kernel
> [   88.000477] c3 Control: 10c53c7d  Table: 9b6ec06a  DAC: 00000015
> [   88.006497] c3
> [   88.006503] c3 PC: 0xc02029cc:
> [   88.011351] c3 29cc  e0614004 ea000003 e3560000 e0855004 15834008
> e3a04000 e2800001 e2833010
> [   88.019773] c3 29ec  e1500007 a3a02000 b3a02001 e3540000 d3a02000
> e3520000 1affffd9 e3540000
> [   88.028275] c3 2a0c  c3e0000b e89daff8 c0bea5d0 e1a0c00d e92ddff0
> e24cb004 e24dd064 e92d4000
> ......
> 
> [   89.134149] c3 [<c0202a4c>] (ecryptfs_encrypt_page+0x34/0x390)
> from [<c0201574>] (ecryptfs_writepage+0x4c/0x9c)
> [   89.134173] c3 [<c0201574>] (ecryptfs_writepage+0x4c/0x9c) from
> [<c00e2a58>] (__writepage+0x24/0x48)
> [   89.134195] c3 [<c00e2a58>] (__writepage+0x24/0x48) from
> [<c00e305c>] (write_cache_pages+0x2f4/0x404)
> [   89.134215] c3 [<c00e305c>] (write_cache_pages+0x2f4/0x404) from
> [<c00e31bc>] (generic_writepages+0x50/0x6c)
> [   89.134234] c3 [<c00e31bc>] (generic_writepages+0x50/0x6c) from
> [<c00e4934>] (do_writepages+0x3c/0x48)
> [   89.134255] c3 [<c00e4934>] (do_writepages+0x3c/0x48) from
> [<c0143ca8>] (writeback_single_inode+0x1c4/0x40c)
> [   89.134276] c3 [<c0143ca8>] (writeback_single_inode+0x1c4/0x40c)
> from [<c0144200>] (writeback_sb_inodes+0x15c/0x214)
> [   89.134295] c3 [<c0144200>] (writeback_sb_inodes+0x15c/0x214)
> from [<c014432c>] (__writeback_inodes_wb+0x74/0xc0)
> [   89.134315] c3 [<c014432c>] (__writeback_inodes_wb+0x74/0xc0)
> from [<c0144538>] (wb_writeback+0x1c0/0x364)
> [   89.134333] c3 [<c0144538>] (wb_writeback+0x1c0/0x364) from
> [<c0144bd4>] (wb_do_writeback+0xf8/0x26c)
> [   89.134352] c3 [<c0144bd4>] (wb_do_writeback+0xf8/0x26c) from
> [<c0144e34>] (bdi_writeback_thread+0xec/0x2e4)
> [   89.134373] c3 [<c0144e34>] (bdi_writeback_thread+0xec/0x2e4)
> from [<c005f3d8>] (kthread+0x9c/0xa8)
> [   89.134393] c3 [<c005f3d8>] (kthread+0x9c/0xa8) from [<c000ff54>]
> (kernel_thread_exit+0x0/0x8)
> [   89.134408] c3 Code: e2864f61 e5963184 e3130004 1a000000 (e7f001f2)

This is a tough one to solve correctly. There's a small amount of time
between eCryptfs creating the file in the lower filesystem and eCryptfs
initializing that file with its metadata. Your device was likely shut
off between those two events.

I see that you're running kernel 3.4.5. In 3.5, I added a (somewhat
ugly) workaround for problems like this:

  e3ccaa9 eCryptfs: Initialize empty lower files when opening them

I think it would solve your problem if you didn't mount with
ecryptfs_passthrough. However, when ecryptfs_passthrough is used,
eCryptfs can't make an assumption about whether an uninitialized lower
file should be turned into an eCryptfs file or if it should remain as a
plaintext file.

Tyler

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]