Sounds promising! I'll give it a try as soon as the official release is
out.
Michael Halcrow wrote the following on 01/09/2008 06:04 PM:
On Thu, Dec 13, 2007 at 01:38:13PM +0100, Stefan Farestam wrote:
I finally got around to testing this again but it still fails, albeit in
a somewhat di
On Thu, Dec 13, 2007 at 01:38:13PM +0100, Stefan Farestam wrote:
> I finally got around to testing this again but it still fails, albeit in
> a somewhat different manner; this time I get a null file in response as
> soon as the file size is above 255 characters in length. Here is
> what I did:
I
There have been a few bugfixes sent upstream recently; I will test
with 2.6.24-rc. In the meantime, I opened a bug ticket for this:
http://sourceforge.net/tracker/index.php?func=detail&aid=1853437&group_id=133988&atid=728799
Thanks,
Mike
On Thu, Dec 13, 2007 at 01:38:13PM +0100, Stefan Farestam
Michael,
I finally got around to testing this again but it still fails, albeit in
a somewhat different manner; this time I get a null file in response as
soon as the file size is above 255 characters in length. Here is what I did:
*
On Fri, Oct 05, 2007 at 03:40:08PM +0200, Stefan Farestam wrote:
> I'm still having problems compiling when using the ubuntu edgy
> kernel. Did you compile against 2.6.22.9?
Yes.
> However, I wasn't sure which function to use to get the "struct
> vfsmount" for the inodes, which the new-style vfs
Hi Michael,
Michael Halcrow wrote the following on 10/05/2007 02:03 AM:
> On Tue, Sep 11, 2007 at 04:45:25PM -0700, Stefan Farestam wrote:
>> I downloaded this new version but couldn't get it to compile on my
>> system (which I just upgraded to Ubuntu Gutsy with the latest set of c
>> librari
On Tue, Sep 11, 2007 at 04:45:25PM -0700, Stefan Farestam wrote:
> I downloaded this new version but couldn't get it to compile on my
> system (which I just upgraded to Ubuntu Gutsy with the latest set of c
> libraries etc). The compile error that I get is (when compiling using
> install.sh):
>
On Tue, Sep 11, 2007 at 04:45:25PM -0700, Stefan Farestam wrote:
> ---
> make[2]: Entering directory `/usr/src/linux-headers-2.6.22-11-generic'
> CC [M]
> /usr/local/src/ecryptfs/src/ecryptfs-20070911/ecryptfs-kernel/ecryptfs/dentry.o
On Tue, Sep 11, 2007 at 04:45:25PM -0700, Stefan Farestam wrote:
> I downloaded this new version but couldn't get it to compile on my
> system (which I just upgraded to Ubuntu Gutsy with the latest set of
> c libraries etc).
Note that the fix for Apache is now in Andrew Morton's tree
(2.6.23-rc6-m
* Michael Halcrow <[EMAIL PROTECTED]> wrote:
> Apache is using sendfile to pipe the contents of a file on disk to
> the network socket. eCryptfs simply forwards the sendfile request
> down to the lower filesystem. This results in the lower buffer
> getting piped through rather than the eCryptfs bu
On Tue, Sep 11, 2007 at 04:45:25PM -0700, Stefan Farestam wrote:
> ---
> make[2]: Entering directory
> `/usr/src/linux-headers-2.6.22-11-generic'
The standalone kernel module only builds against 2.6.16 through 2.6.21
at the moment. I
Michael Halcrow wrote the following on 09/11/2007 01:45 PM:
> I found the problem.
>
> Apache is using sendfile to pipe the contents of a file on disk to the
> network socket. eCryptfs simply forwards the sendfile request down to
> the lower filesystem. This results in the lower buffer getting pi
I found the problem.
Apache is using sendfile to pipe the contents of a file on disk to the
network socket. eCryptfs simply forwards the sendfile request down to
the lower filesystem. This results in the lower buffer getting piped
through rather than the eCryptfs buffer, so it is obviously the wro
On Sat, Sep 08, 2007 at 04:36:06PM -0500, Trevor Highland wrote:
> I was able to reproduce what you are seeing. I turned on debug
> statements and discovered a few things that stand out. When a file
> is accessed through apache the file is opened properly through
> ecryptfs, which includes reading
Hi,
I was able to reproduce what you are seeing. I turned on debug statements
and discovered a few things that stand out. When a file is accessed through
apache the file is opened properly through ecryptfs, which includes reading
the header of the file. Once the file is open I see no sign of eCr
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)
On Thu, Sep 06, 2007 at 08:31:54PM +0200, Stefan Farestam wrote:
> 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!
Then I am inclined to blame some sort of caching in Apache. If
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
On Thu, Sep 06, 2007 at 05:53:36PM +0200, Stefan Farestam wrote:
> Kent Yoder wrote the following on 09/06/2007 05:47 PM:
> >
> >Hmm, if you were serving files out of the lower mount, the headers of
> >the files would look the same like this... Is Apache pointed at the
> >upper mount?
> >
> Yes it
[EMAIL PROTECTED] wrote on 09/06/2007 10:34:07
AM:
>
> Hi,
>
> 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 s
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
Kent Yoder wrote the following on 09/06/2007 05:47 PM:
Hmm, if you were serving files out of the lower mount, the headers of
the files would look the same like this... Is Apache pointed at the
upper mount?
Yes it is. The lower mount is $HOME/protected/encrypted which is mounted
as an overlay
Hmm, if you were serving files out of the lower mount, the headers of
the files would look the same like this... Is Apache pointed at the
upper mount?
On 9/6/07, Stefan Farestam <[EMAIL PROTECTED]> wrote:
>
>
> Hi,
>
> When using a directory encrypted with ecryptfs to serve an apache webserver
Hi,
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
24 matches
Mail list logo
