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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 12 Feb 2009 16:27:14 +0100 (CET)
From:	Jan Engelhardt <jengelh@...ozas.de>
To:	John Ogness <dazukocode@...ess.net>
cc:	linux-kernel@...r.kernel.org, viro@...iv.linux.org.uk,
	malware-list@...ts.printk.net, eparis@...hat.com,
	hch@...radead.org, alan@...rguk.ukuu.org.uk
Subject: Re: [PATCHv2 1/5] VFS: DazukoFS, stackable-fs, file access control


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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/