Re: [PATCHv2 1/5] VFS: DazukoFS, stackable-fs, file access control

[Jan Engelhardt]

On Tuesday 2009-02-03 20:15, John Ogness wrote:

>Patch 1: Introduces DazukoFS as a nullfs. This is the raw stackable
>         filesystem part of DazukoFS and does nothing except stack and
>         pass filesystem calls to the lower filesystem.
>
>Patched against 2.6.29-rc3.
>
>Index: linux-2.6.28/Documentation/filesystems/dazukofs.txt
>===================================================================
>--- /dev/null	1970-01-01 00:00:00.000000000 +0000
>+++ linux-2.6.28/Documentation/filesystems/dazukofs.txt	2009-02-03 18:07:44.000000000 +0100
>+
>+=====================
>+ MOUNTING/UNMOUNTING
>+=====================
>+
>+DazukoFS is typically mounted on top of an existing directory. For example,
>+to stack DazukoFS on top of the /opt directory, the following mount(8)
>+command can be given:
>+
>+# mount -t dazukofs /opt /opt
[...]
>+# mount -t dazukofs /opt /mnt
>+
>+When accessing files within /mnt, you will be accessing files in /opt
>+(through DazukoFS). When accessing files directly in /opt, DazukoFS will not
>+be involved.
>+
>+THIS HAS POTENTIAL PROBLEMS!

This ought to be done better in light of the problem that one
could issue `mount -t dazukofs /mnt /opt`
In kernel code, I'm thinking something like

static int foofs_dothis(...)
{
	buf = call d_path on sb->s_root
	call namei_lookup on buf
	use lookup's resulting dentry as source directory
}

This assumes at least that namei_lookup will not return the new SB's
dentry for the given path.
Iff that works out somehow, the 'device' part in the mount command
line is practically ignored like it is for like procfs.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/