lkml.org 
[lkml]   [2012]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ 026/180] eCryptfs: Improve statfs reporting
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/01/2012 11:46 PM, Tyler Hicks wrote:
> On 2012-10-02 00:52:23, Willy Tarreau wrote:
>> 2.6.32-longterm review patch. If anyone has any objections,
>> please let me know.
>
> Hi - Please drop this patch. It incorrectly calculates f_namelen
> and I haven't had a chance to fix it yet. When I get a fix ready,
> I'll forward the corrected patch to stable@v.k.o. Thanks!
>
> Tyler
>
>>
>> ------------------
>>
>> From: Tyler Hicks <tyhicks@canonical.com>
>>
>> commit 4a26620df451ad46151ad21d711ed43e963c004e upstream.
>>
>> BugLink: http://bugs.launchpad.net/bugs/885744
>>
>> statfs() calls on eCryptfs files returned the wrong filesystem
>> type and, when using filename encryption, the wrong maximum
>> filename length.
>>
>> If mount-wide filename encryption is enabled, the cipher block
>> size and the lower filesystem's max filename length will
>> determine the max eCryptfs filename length. Pre-tested, known
>> good lengths are used when the lower filesystem's namelen is 255
>> and a cipher with 8 or 16 byte block sizes is used. In other,
>> less common cases, we fall back to a safe rounded-down estimate
>> when determining the eCryptfs namelen.
>>
>> https://launchpad.net/bugs/885744
>>
>> Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Reported-by:
>> Kees Cook <keescook@chromium.org> Reviewed-by: Kees Cook
>> <keescook@chromium.org> Reviewed-by: John Johansen
>> <john.johansen@canonical.com> Signed-off-by: Colin Ian King
>> <colin.king@canonical.com> Acked-by: Stefan Bader
>> <stefan.bader@canonical.com> Signed-off-by: Tim Gardner
>> <tim.gardner@canonical.com> Signed-off-by: Willy Tarreau
>> <w@1wt.eu> --- fs/ecryptfs/crypto.c | 68
>> ++++++++++++++++++++++++++++++++++++----
>> fs/ecryptfs/ecryptfs_kernel.h | 11 ++++++
>> fs/ecryptfs/keystore.c | 9 ++--- fs/ecryptfs/super.c
>> | 18 ++++++++++- 4 files changed, 92 insertions(+), 14
>> deletions(-)

Tyler - this is the same patch that we're carrying in every kernel
from Lucid to Quantal, right ? Colin has verified test cases for this,
so I'm curious what you think is wrong. Something unique to 2.6.32 ?

https://bugs.launchpad.net/ecryptfs/+bug/885744/comments/5
https://bugs.launchpad.net/ecryptfs/+bug/885744/comments/9

rtg
- --
Tim Gardner tim.gardner@canonical.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCgAGBQJQatzmAAoJED12yEX6FEfKwpsP/jgSVRAb3X/Xu1Hob46T2TD3
XFClsr4xWlRzrHKsKxDHZxYUKy6TexEB9ZagjfFIlteqbyEqOB+Eq/p7cFrouIlm
nX4/ERslly1H1tvm9x7hc3fUN3M8C5dwWsARjiRHY3luEZapIyMETnrikhahpZM5
xferd8RIowgTkDUfnLwBVhwagJSvpaBgavJq1Kn5+6ArEPWtT1AeiybHoJ0fOTb8
uNuCTjSHOhZh5ssConAyxhPiCgl0NYBdzHNPmuc+jO0ZDfb9NFfnNUUB6lRdrVhe
QJBXX1N4N90R70nnQBHFNWJCdMJpjbE80PdE/T8IAsUqa8IFpHzfZZJYRgMVUbc9
2nkQ+ZLTSOIy2IZSCGZzWA/kf9bRGuUF/KcPizpKEB7s2QDlPp3Rrt/zs1DRbnt5
FBWmfgtb37Hpz94EGaMQzTIAj0iZXqZ68njww3c1ELllCMmj+z/0UKktLCOhz3dO
ntlp8EUAD1F+Z5cMYxEP20Gn3EVvENSDfJnpdzWgTYzqNqFixCTC+cOWLl3OmCoL
2XxYDG6b6N6Y0dYMxjQV/DrptEXzr4kl70mLTa6yED6a3uxSSDGwRpM16feBR785
a83u27nVe9DLwJIo4D/gxmTiCsYZ7N5Y62hFMSwYgBFYrKDEq2wK6XizCerr11RB
NZ3Rh1IDrSVxBPwqpS/w
=z24H
-----END PGP SIGNATURE-----


\
 
 \ /
  Last update: 2012-10-02 15:01    [W:0.661 / U:1.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site