headers
Lino Sanfilippo | 18 Jun 2009 18:27
Favicon

Bug in stackable filesystems like wrapfs, ecryptfs etc.


Hello,

our company is working with the stackable filesystem dazukofs that is 
based on wrapfs from the FiST
project.

We discovered a bug in the case that a stackable filesystem like 
ecryptfs, wrapfs or dazukofs,
is stacked upon itself, i.e by mounting it several times at the same 
mount point.

An access to a file (i.e. by touching it) through 3 or more layers of 
one of those stackable filesystems,
results in an Oops.
The reason is the usage of the lookup_one_len() function, which passes a 
NULL nameidata
to the lower filesystem if it has the d_revalidate() dentry operation 
defined.

Thus, stackable filesystem like wrapfs, ecryptfs and dazukofs assume 
that the filesystem below it handles
NULL values for the nameidata correctly, which might not be true:

Ironically these stackable filesystems themselves, are not prepared to 
handle those NULL values.
So if the underlaying filesystem is one of those stackable filesystems, 
it might try to access
the nameidata struct and the Oops occurs due to the access of a NULL 
pointer.
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Ogness | 28 Jun 2009 23:37

DazukoFS 3.1.0-rc1 posted

Hi,

I spent last week at the LinuxTag 2009 conference in Berlin. There I
unexpectedly met up with Lino Sanfilippo. Together we had a great
hacking session and were able to tackle a lot of DazukoFS issues. Some
of these include:

- Finally handling mmap() cleanly! PROT_WRITE is now correctly
  unsupported so applications can safely fallback to regular file IO.

- Fixed a bug when multiple stackable filesystems are stacked onto
  each other. All other stackable filesystems also have this bug at
  the moment. I plan to submit a patch to mainline to fix ecryptfs as
  well.

- As suggested on LKML, we are now using the pid framework. This
  should allow DazukoFS to work correctly with pid namespaces. (If you
  use pid namespaces, I would greatly appreciate testing feedback.)

- Reading directories is now handled correctly. Until now you could
  sometimes see "invalid argument" error messages when using the grep
  tool. ecryptfs also has this problem. I plan to submit a patch to
  mainline to fix ecryptfs as well.

- libdazukofs will now allow dazukofs_open() to be successful for a
  read-only /dev/dazukofs.ctrl if the group already exists. This makes
  it possible to run full on-access scanners _without_ever_ starting
  the application as root.

Version 3.1.0-rc1 has been updated to support Linux 2.6.30. Right now
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Ogness | 29 Jun 2009 23:05

fanotify post to LKML

Hi,

After successfully unifying dnotify and inotify, Eric Paris has posted
his next plans to merge fanotify to Linux mainline. If merged, this
would also serve to provide on-access scanners with an effective
interface to the kernel. Eric's email can be found here:

http://lkml.org/lkml/2009/6/29/407

John Ogness

--

-- 
Dazuko Maintainer
Permalink | Reply | 0 comments |
headers
Lino Sanfilippo | 1 Jul 2009 18:31
Favicon

Patch for mmap Bug in dazukofs 3.1.0-rc1


Hi all,

although the new mmap() approach (deny writing, allow reading) used by
dazukofs 3.1.0-rc1 works very fine so far (the BUG reported on dazukofs 
help mailing list:
http://lists.gnu.org/archive/html/dazuko-help/2009-04/msg00008.html
seems to be fixed), there is still a litte flaw:

If the underlaying filesystem does not support mmap() for a regular file 
or a directory,
we must not call generic_file_readonly_mmap() for this file type:
Calling this function always results in calling the lower address_space 
objects readpage()
(see read_cache_page() in mmap.c).  But this might not be initialized if 
no mmap() is supported,
so we run into an Oops in this case.

This bug can simply be triggered by mounting dazukofs over an ext3 - 
which does not provide
mmaping for directories - and reading an arbitrary directory via mmap.

Please see also the description for patch 2 for dazukofs release 3.0.0.

This patch ensures that generic_file_readonly_mmap() is only called if 
the lower file actually
supports mmap.
If not the error code -ENODEV, which is used by the vfs to indicate that 
mmap is not supported,
is returned.
(Continue reading)

Permalink | Reply | 2 comments |

Gmane