Thanks for the quick response.

Re Lookup intents, yes, I did see a kernel panic with intent of OPEN.

The following work around seems to have resolved the problem. Can you
please help me figure out if this is OK to do or not?

In ecryptfs_lookup(), instead of calling lookup_one_len(), what if we
directly call the lower layer lookup so that the flags in nd also are
passed down.

        lower_dentry = d_lookup(lower_dir_dentry, &dentry->d_name);
        if (!lower_dentry) {
                
                temp_dentry = d_alloc(lower_dir_dentry, &dentry->d_name);
                if (temp_dentry) {
                        lower_dentry =
lower_dir_dentry->d_inode->i_op->lookup(lower_dir_dentry->d_inode,
                                                                                
                                                        temp_dentry, nd);
                        if (lower_dentry)
                                dput(temp_dentry);
                        else
                                lower_dentry = temp_dentry;
                }
                rc = -ENOMEM;
                d_drop(dentry);
                goto out;
        }       


On 7/17/07, Michael Halcrow <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 17, 2007 at 04:30:41PM -0700, Rajouri Jammu wrote:
> > I'm interested in running ecryptfs on networked file systems.
> >
> > I noticed the following comment in the sources.
> >
> > > /**
> > >  * This is a temporary hack to prevent inadvertent mounting on lower
> > >  * filesystems that are known to be currently incompatible with
> > >  * eCryptfs. This mainly includes networked filesystems.
> > >  */
> >
> > Can someone please let me know why ecryptfs is not compatible with
> > NFS?
>
> Here is a short laundry list:
>
>  - Lookup intents have been problematic with stacked filesystems on
>    NFS.
>  - writepages() NULL ptr deref, which might have a fix:
>   - http://www.mail-archive.com/[EMAIL PROTECTED]/msg06097.html
>  - Unlinks keep sillyrenamed files around until eCryptfs is
>    unmounted. I have no idea why.
>
> Mike
> .___________________________________________________________________.
>                          Michael A. Halcrow
>        Security Software Engineer, IBM Linux Technology Center
> GnuPG Fingerprint: 419C 5B1E 948A FA73 A54C  20F5 DB40 8531 6DCA 8769
>
> If this is flashing then you're a winner!
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iQEVAwUBRp1qU9tAhTFtyodpAQM2Bwf/UknPunsBANZLHTXB6aTNo955/BQ8tb1E
> WxHQj+VF8QWrfaYdg0tgdYhaIvagYNpCq5HMDWQHr4FNGpgQNu8uqQ3fsu/pIMWK
> AGtlRUFCNzT9sJME9Xiigp2qu7WZ67vjenrYYErfT9rmeiF/FW6T1qd155yYQdmu
> hh277TIybVDlHO7jzfgJkJr94CaQr9smubUhcQkm2AkPIiyvOwN/LGHlxvboS2l/
> mJQgZHZdZ/v1J0sJq2TpPdj9svKCYEdRodZzWMMRgFNrxjnSZ2lrqm+g8qUxmyda
> OnJjde4oJ0Vb5ER54E5ErMWnK47tvwhZhBw/J4XS+ZULs1MAZ5JfCQ==
> =L03Z
> -----END PGP SIGNATURE-----
>
>

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
eCryptfs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel

Reply via email to