cannot enter subdirs of overlayed dwarfs about dwarfs

[cipitaua]

yes, sorry I forgot to answer. By setting the usual permission rwxr-xr-x to folders, the newly created dwarfs works as expected 👍

[mhx]

Thanks for your report, @cipitaua!

Nice catch, this is indeed a bug in how DwarFS implements the access system call. Funnily enough, while you can't cd to archive/media, you can list/read it's contents and even create files. Also, once you've created a file in the directory - even if you immediately delete it again - you can cd into the directory without issues. The latter is presumably because the directory now exists in archive-rw and so archive-ro/media is no longer checked for access permissions.

I've got a fix for the issue locally, but I'll need to double check and run a few tests before pushing a new release.

[cipitaua]

Thank you for the prompt reply.

What's not clear is why I've encountered the bug only in this case but never before, although I've used dwarfs in this way (with overlay) a lot of times for over one year, starting with dwarfs version 0.6.9.

Also it's not clear to me whether the bug is in the archive.dwarfs I have produced, or it is in the mount.dwarfs code.

[cipitaua]

any hint?

[mhx]

Sorry, I completely missed your reply.

What's not clear is why I've encountered the bug only in this case but never before, although I've used dwarfs in this way (with overlay) a lot of times for over one year, starting with dwarfs version 0.6.9.

That is a very good question. Here's some more detail:

The bug that I found and that seems to cause this particular problem is in DwarFS' implementation of the access system call. The bug is that the implementation didn't handle the root user id any different from a regular user, whereas the expectation is that "The super-user can read and write any file, and execute any file that anyone can execute". The "execute" part extends to "being able to enter directories" for directory inodes.

This obviously has nothing to do directly with overlaying file systems. However, since the overlay mount is run as root and (seemingly) all access to the read-only layer will be performed from the root user id (thus also requiring -o allow_root), if the overlayfs code happens to use access(), DwarFS will currently report an error, and this can cause things like changing to the directory to fail.

Now this raises a bunch of questions:

• Did overlayfs always behave that way, or is the access call something that was recently introduced?
• Does overlayfs actually have to run as root? Does it have to perform requests "as-root"?

So, unfortunately, I can't provide a definitive answer to your question.

Also it's not clear to me whether the bug is in the archive.dwarfs I have produced, or it is in the mount.dwarfs code.

Your archive.dwarfs is perfectly okay. The bug described above is in the DwarFS FUSE driver (i.e. mount.dwarfs).

[cipitaua]

I see. However I'm using many dwarfs archives with overlay and only that one has 'access' problems.

[mhx]

I see. However I'm using many dwarfs archives with overlay and only that one has 'access' problems.

Maybe the directory permissions are different for your other archives?

$ ls -ld archive/media
drwx------ 1 guest guest 66  6 apr  2012 archive/media

I assume that if the directory was world-executable, you wouldn't run into the problem.

[mhx]

@cipitaua, did you check the directory permissions in your other archives by any chance?

[mhx]

Thanks! I'll nonetheless roll a new release with the fix in the next couple of days.

[mhx]

Fixed in v0.9.7.