linux-kernel - Re: overlayfs: "filesystem of lowerdir is not supported" on cdrom

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]

Message-ID: <20141028211313.GB7996@ZenIV.linux.org.uk>
Date:	Tue, 28 Oct 2014 21:13:13 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Tim Tassonis <stuff@...entral.ch>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: overlayfs: "filesystem of lowerdir is not supported" on cdrom

On Tue, Oct 28, 2014 at 07:10:36PM +0100, Tim Tassonis wrote:
> Hi
> 
> Just installed 3.18-rc2 and tried to test the overlayfs stuff:
> 
> $ mkdir /ovtmp
> $ mount -t tmpfs tmpfs /ovtmp/
> $ mkdir /ovtmp/work
> $ mkdir /ovtmp/upper
> $ mkdir /cdrw
> $ mount /dev/sr0 /mnt
> $ mount |egrep "ovtmp|sr0"
> 
> /dev/sr0 on /mnt type iso9660 (ro,relatime)
> tmpfs on /ovtmp type tmpfs (rw,relatime)
> 
> $ mount -t overlayfs overlayfs \
>  -olowerdir=/mnt,upperdir=/ovtmp/upper,workdir=/ovtmp/work /cdrw

> [ 3266.793218] overlayfs: filesystem of lowerdir is not supported
> 
> However, the doc in Documentation/filesystems/overlayfs.txt states:
> 
> "The lower filesystem can be any filesystem supported by Linux and does
> not need to be writable.  The lower filesystem can even be another
> overlayfs.  The upper filesystem will normally be writable and if it
> is it must support the creation of trusted.* extended attributes, and
> must provide valid d_type in readdir responses, so NFS is not suitable."
> 
> So: Is the documentation wrong, the error message in dmesg wrong, or
> have missed something completely?

Documentation is wildly over-optimistic.  You are trying to use something
with non-trivial ->d_hash and ->d_compare as lower layer.

What should happen if you ask to mount an image with joliet extensions and
ask to create foo.txt.... when foo.txt is there?  From the isofs POV those
are the same; for overlayfs they are not (it's using default ->d_hash
and ->d_compare).

We probably ought to split the normal (case-sensitive, no joliet shite) case
out and leave it with NULL ->s_d_op, but that'll need to be done carefully,
or isofs_cmp() will blow up on us.
--
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/