Michael Halcrow wrote the following on 09/06/2007 05:51 PM:
On Thu, Sep 06, 2007 at 05:34:07PM +0200, Stefan Farestam wrote:
When using a directory encrypted with ecryptfs to serve an apache
webserver I am only getting garbage. The bizarre thing is that I have
no problem using the files from the encrypted directory when using other
applications such as emacs or the openoffice tools. To add to the
mystery, the files that are served are of identical length to the
original files and they all start with the roughly the same sequence of
bytes (dumped here using "od -c", note the occurrence of the strings
"3DUfw" and "_CONSOLE"):
These are the encrypted versions of the files; in other words, they
are the files in the lower filesystem, not the files in the eCryptfs
filesystem. Make sure that Apache is reading the files from the
correct directory. Keep in mind that, if you are doing an overlay
mount, there is no guarantee that any given application does not have
any references to the lower filesystem objects that were obtained
prior to performing the eCryptfs mount.
Ok. To ensure that apache did not read the files from the encrypted
directory I changed the configuration to store the encrypted files in
$HOME/encrypted and mount them in $HOME/protected. I also restarted
apache, performed a mount/umount cycle. However no change in behavior.
At this point I thought that I observed some obscure caching behavior so
I decided to create a small testfile containing:
abcdefghijklmnopqrstuvwxyz
12345678901234567890123456
To my big surprise, this file came though just fine while other files in
the same directory were garbled up. I then appended the text content of
a file that was garbled to the testfile and suddenly the testfile became
garbled! My immediate guess was that I had managed to copy over some
obscure characters that triggered a bug so I removed the added text and
the file came through fine again.
To cut a long story short I discovered that the file became garbled as
soon as the length exceeded 255 bytes, and only when requested through
the apache web server!
This file comes through fine:
--- start
abcdefghijklmnopqrstuvwxyz
12345678901234567890123456
abcdefghijklmnopqrstuvwxyz
12345678901234567890123456
abcdefghijklmnopqrstuvwxyz
12345678901234567890123456
abcdefghijklmnopqrstuvwxyz
12345678901234567890123456
abcdefghijklmnopqrstuvwxyz
12345678901
--- end
This file becomes garbled:
--- start
abcdefghijklmnopqrstuvwxyz
12345678901234567890123456
abcdefghijklmnopqrstuvwxyz
12345678901234567890123456
abcdefghijklmnopqrstuvwxyz
12345678901234567890123456
abcdefghijklmnopqrstuvwxyz
12345678901234567890123456
abcdefghijklmnopqrstuvwxyz
123456789012
--- end
od -c on the garbled file when downloaded using wget:
--- start
0000000 \0 \0 \0 \0 \0 \0 001 \0 & 223 325 204 032 022 b q
0000020 002 \0 \0 002 \0 \0 \0 \0 001 214 - 004 \t 003 001
0000040 \0 021 " 3 D U f w ` 347 b r 337 373 ; s
0000060 024 234 r 225 241 273 212 023 , 267 347 370 004 337 030 220
0000100 V 310 344 262 & T K 267 [ 355 026 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
*
0000400
--- end
od -c on the file in the lower encrypted file system:
--- start
0000000 \0 \0 \0 \0 \0 \0 001 \0 & 223 325 204 032 022 b q
0000020 002 \0 \0 002 \0 \0 \0 \0 001 214 - 004 \t 003 001
0000040 \0 021 " 3 D U f w ` 347 b r 337 373 ; s
0000060 024 234 r 225 241 273 212 023 , 267 347 370 004 337 030 220
0000100 V 310 344 262 & T K 267 [ 355 026 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
*
0020000 230 017 - 267 d M 021 227 346 006 c Q 022 a 265 227
0020020 032 255 y 342 ( 242 h 335 334 222 017 3 ( 037 l 301
0020040 * 264 2 R 225 022 Y L . Y 346 2 273 001 021 h
0020060 200 E \f 274 336 j 321 \a 370 b x 254 E * 213 ]
0020100 005 E g 226 365 216 311 340 347 033 X d + 372 8 267
0020120 017 363 261 257 235 213 217 216 O M 276 342 V i 311 324
0020140 240 b = E 257 205 7 y 8 C 020 351 242 327 v 367
0020160 N 224 \f u 8 246 T @ 214 203 < 340 \n - 247 346
0020200 245 323 \ 003 H x 317 307 264 342 346 . 203 365 305 345
0020220 t 337 311 b j h 233 225 324 335 ( 237 033 5 : 1
0020240 9 001 354 021 261 017 266 _ X " N 335 v \n v (
**** this portion omitted ********
0027640 255 233 265 " 001 e 262 347 364 260 337 335 222 263 k 323
0027660 252 006 337 207 r 005 v \r 321 Y 327 % y = c 250
0027700 221 037 263 250 \f 334 _ 255 034 232 331 i 272 314 350 a
0027720 233 375 334 211 } - 312 026 215 373 372 257 006 272 246 232
0027740 243 ! 216 353 > 200 324 237 354 y 231 016 v V 030 005
0027760 5 346 345 335 341 315 316 034 262 h 266 344 g % q 235
0030000
--- end
As can be seen, apache is indeed serving up the header of the encrypted
file, but nothing more.
Any guesses as to what might be going on here?
Many thanks for the rapid response,
Stefan
--
Stefan Farestam
Mobile: +46 70 649 6838
--
Stefan Farestam
Mobile: +46 70 649 6838
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
eCryptfs-users mailing list
eCryptfs-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecryptfs-users
