linux-kernel - Re: [PATCH 0/5] hybrid union filesystem prototype

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:	Tue, 31 Aug 2010 11:05:18 -0400
From:	Kyle Moffett <kyle@...fetthome.net>
To:	Neil Brown <neilb@...e.de>
Cc:	Miklos Szeredi <miklos@...redi.hu>, vaurora@...hat.com,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	viro@...iv.linux.org.uk, jblunck@...e.de, hch@...radead.org
Subject: Re: [PATCH 0/5] hybrid union filesystem prototype

On Tue, Aug 31, 2010 at 07:24, Neil Brown <neilb@...e.de> wrote:
> On Tue, 31 Aug 2010 13:00:45 +0200 Miklos Szeredi <miklos@...redi.hu> wrote:
>> No, I don't think this design will do that.  So it might be enough
>> just to document that online modification of upper or lower
>> filesystems results in undefined behavior.
>>
>> But to prevent accidental damage, it's prudent (at least by default)
>> to enforce the no-modification policy.
>>
>> Why do you think this feature of allowing modification is important?
>> Lets take some typical use cases:
>>
>>  - live cd: lower layer is hard r/o, upper layer makes no sense to
>>    modify online
>>
>>  - thin client: lower layer is static except upgrades, which need
>>    special tools to support and is done offline, upper layer makes no
>>    sense to modify online
>>
>> Do you have some cases in mind where it makes at least a little sense
>> to allow online modification of the underlying filesystems?
>
> No, I don't have a particular use case in mind that would take advantage of
> the layers being directly modifiable.  But I know that sys-admins can be very
> ingenious and may well come up with something clever.
>
> My point is more that I don't think that is it *possible* to prevent changes
> to the underlying filesystem (NFS being the prime example) so if there are
> easy steps we can take to make the behaviour of overlayfs more predictable in
> those cases, we should.

There's certainly already weird behaviors you can cause by regular
filesystem over-mounts on NFS.  For example, I have an NFS server that
exports a "/srv/git" directory; if I was to do the following actions
on a client:

# mkdir /srv/git
# mount -t nfs myserver:/srv/git /srv/git
# mkdir /srv/git/mnt
# mount -t ext3 /dev/sda3 /srv/git/mnt

And then from the server I were to:
# rmdir /srv/git/mnt

Terrible terrible things would happen... by which I mean I can no
longer access or unmount that filesystem from the client.  That use
case in particular seems to be much worse than your regular unionfs
example even, and it's easily possible today (even by accident).

Cheers,
Kyle Moffett
--
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/