Hi again,
I've investigated a bit more thoroughly into this problem, but I am
still observing the same strange behavior. This time around I used
strace on the apache server process and verified that apache did indeed
only access the unencrypted file ($HOME/b/testfile.txt in the example
below).
Here is the exact procedure that I have followed:
* reboot
* stop any running instances of apache:
% apache2ctl stop
* delete and recreate the directories $HOME/a and $HOME/b
% rm -rf $HOME/{a,b}
% mkdir $HOME/{a,b}
* mount the encrypted directory as root (plaintext passthrough disabled):
% mount -t ecryptfs $HOME/{a,b} -o cipher=aes,ecryptfs_key_bytes=32
* mtab entry becomes:
% fgrep $HOME/a /etc/mtab
/home/test/a /home/test/b ecryptfs
rw,ecryptfs_sig=4733efbff603498e,ecryptfs_cipher=aes,ecryptfs_key_bytes=32
0 0
* create testfile
% cat << EOF > $HOME/b/testfile.txt
123456789-123456789-123456789-123456789-123456789-
123456789-123456789-123456789-123456789-123456789-
123456789-123456789-123456789-123456789-123456789-
123456789-123456789-123456789-123456789-123456789-
123456789-123456789-123456789-123456789-123456789-
123456789-123456789-123456789-123456789-123456789-
EOF
* start apache
% apache2ctl start
* retrieve file with wget
% wget http://localhost/home/b/testfile.txt
* check what we have:
% od -c testfile.txt
--- start
0000000 \0 \0 \0 \0 \0 \0 001 2 360 022 \b + 314 223 277 336
0000020 002 \0 \0 002 \0 \0 \0 \0 001 214 - 004 \t 003 001
0000040 \0 021 " 3 D U f w ` 336 361 ! s 326 262 220
0000060 272 356 h $ 5 : % w 364 d 231 \t 030 200 330 351
0000100 t 210 273 324 217 e 366 331 373 355 025 b \b _ C O
0000120 N S O L E \0 \0 \0 \0 G 3 357 277 366 003 I
0000140 216 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000160 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0000460 \0 \0
0000462
--- end
As I have previously noted the behavior appears only when the file is
longer than 255 bytes.
Variants of the above that I have tried (with the same result):
* Used algorithms "aes" and "blowfish"
* Varied blocksize from 32 to 16
* Used Ubuntu kernel vmlinuz-2.6.20-16-generic with the
ecryptfs module supplied with that kernel distribution
* Used custom compiled kernel vmlinuz-2.6.21.7 with kernel supplied
ecryptfs module
* Used custom compiled kernel vmlinuz-2.6.22.6 with kernel supplied
ecryptfs module
* Used custom compiled kernel vmlinuz-2.6.23-rc5 with kernel supplied
ecryptfs module
I would be happy to run any other tests that someone suggests.
--
Stefan Farestam
Mobile: +46 70 649 6838
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
eCryptfs-users mailing list
eCryptfs-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecryptfs-users
