From: John Ogness <dazukocode@ogness.net>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Jan Engelhardt <jengelh@medozas.de>,
linux-kernel@vger.kernel.org, malware-list@lists.printk.net,
eparis@redhat.com, hch@infradead.org, alan@lxorguk.ukuu.org.uk
Subject: Re: [PATCHv2 1/5] VFS: DazukoFS, stackable-fs, file access control
Date: Sat, 14 Feb 2009 09:43:04 +0100 [thread overview]
Message-ID: <86eiy1v27b.fsf@johno.fn.ogness.net> (raw)
In-Reply-To: <20090213202523.GN28946@ZenIV.linux.org.uk> (Al Viro's message of "Fri\, 13 Feb 2009 20\:25\:23 +0000")
On 2009-02-13, Al Viro <viro@ZenIV.linux.org.uk> wrote:
>> You could write an additional mount helper (and putting that into
>> /sbin/mount.dazukofs) that does all the security checks:
>>
>> - that the device is the same as mountpoint
>> - that the device belonging to the underlying '/mnt' is not
>> mounted anywhere else (in this namespace, at least)
>> - exit(1) otherwise
>>
>> Sure, it may not protect against all the cases Al can come up with,
>> but it is better than having nothing.
>
> It's still racy, at the very least. Folks, seriously, you can not
> rely on the underlying tree being inaccessible elsewhere. Anything
> that does stacking has to cope with that possibility; it's not
> bypassable by userland helpers.
Indeed. As long as the stackable filesystem is synchronizing with the
lower layer before doing read actions and synchronizes after all
actions, there should be no problem.
Currently I see a problem when a new directory is created directly on
the lower mount (rather than through the stackable filesystem). A
refcount for "." as seen from the stackable filesystem is then
incorrect. I will investigate this.
And I will look to see why there is any danger at all. There should
not be.
John Ogness
prev parent reply other threads:[~2009-02-14 8:43 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-03 19:14 [PATCHv2 0/5] VFS: DazukoFS, stackable-fs, file access control John Ogness
2009-02-03 19:15 ` [PATCHv2 1/5] " John Ogness
2009-02-03 19:17 ` [PATCHv2 2/5] " John Ogness
2009-02-03 19:18 ` [PATCHv2 3/5] " John Ogness
2009-02-03 19:19 ` [PATCHv2 4/5] " John Ogness
2009-02-03 19:20 ` [PATCHv2 5/5] " John Ogness
2009-02-12 20:24 ` Eric W. Biederman
2009-02-12 20:20 ` [PATCHv2 3/5] " Eric W. Biederman
2009-02-17 8:55 ` John Ogness
2009-02-18 0:41 ` Eric W. Biederman
2009-02-21 18:11 ` [malware-list] " Frantisek Hrbata
2009-02-12 16:00 ` [PATCHv2 2/5] " Jan Engelhardt
2009-02-13 19:33 ` John Ogness
2009-02-12 20:14 ` Eric W. Biederman
2009-02-13 19:39 ` John Ogness
2009-02-12 15:27 ` [PATCHv2 1/5] " Jan Engelhardt
2009-02-12 15:31 ` Al Viro
2009-02-12 15:59 ` Jan Engelhardt
2009-02-12 16:47 ` Al Viro
2009-02-13 19:31 ` John Ogness
2009-02-13 19:48 ` Al Viro
2009-02-13 20:00 ` Jan Engelhardt
2009-02-13 20:25 ` Al Viro
2009-02-14 8:43 ` John Ogness [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86eiy1v27b.fsf@johno.fn.ogness.net \
--to=dazukocode@ogness.net \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=eparis@redhat.com \
--cc=hch@infradead.org \
--cc=jengelh@medozas.de \
--cc=linux-kernel@vger.kernel.org \
--cc=malware-list@lists.printk.net \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox