Thank you for the pointers!

On 7/18/07, Michael Halcrow <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 18, 2007 at 12:53:08AM -0700, Rajouri Jammu wrote:
> > 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?
>
> This issue has been given a hard look over the last several months by
> various members of the kernel community and by the Unionfs guys. You
> probably want to get familiar with those discussions before you go too
> far forward with a proposed fix. Here was the first false start:
>
> http://lkml.org/lkml/2007/3/9/95
> http://lkml.org/lkml/2007/3/9/238
>
> So the lookup_one_len_nd() approach won't work. Jeff Sipek tells me
> that Andrew Morton has patches, possibly going into 2.6.23, that
> introduce vfs_path_lookup(). So far, this allows file create on
> NFS.
>
> http://lkml.org/lkml/2007/5/23/483
>
> Really, the problem has to do with how NFS handles things *after* the
> lookup.
>
> http://www.fsl.cs.sunysb.edu/~jsipek/kernel/how_to_do_lookups_the_right_way.txt
>
> In short, the solution is going to have to touch code outside of
> eCryptfs. It might be necessary to split open_namei() (fs/namei.c) to
> really do this right.
>
> > 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
>
>

-------------------------------------------------------------------------
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