Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cannot enter subdirs of overlayed dwarfs #204

Closed
cipitaua opened this issue Mar 16, 2024 · 10 comments
Closed

cannot enter subdirs of overlayed dwarfs #204

cipitaua opened this issue Mar 16, 2024 · 10 comments
Assignees
Labels
bug Something isn't working
Milestone

Comments

@cipitaua
Copy link

cipitaua commented Mar 16, 2024

Hello,

I've made a dwarfs of a folder named archive.orig, and mounted it as

mkdwarfs -L 10g -i archive.orig -o archive.dwarfs
mount.dwarfs archive.dwarfs archive-ro -o allow_root

and then I've overlayed it:

sudo mount -t overlay overlay -o lowerdir=archive-ro,upperdir=archive-rw,workdir=archive-work  archive

with no warning or errors.

However, when I try to access the files in a subdir of 'archive':

$ cd archive/media
bash: cd: archive/media: Permission denied

although:

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

I also note that if I overlay directly the 'archive.orig':

sudo mount -t overlay overlay -o lowerdir=archive.orig,upperdir=archive-rw,workdir=archive-work  archive

then I can access 'archive' subfolders normally. Therefore I guess it could be related to dwarfs.
Any idea?

@mhx
Copy link
Owner

mhx commented Mar 16, 2024

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.

@mhx mhx self-assigned this Mar 16, 2024
@mhx mhx added the bug Something isn't working label Mar 16, 2024
@mhx mhx added this to the v0.9.7 milestone Mar 16, 2024
@cipitaua
Copy link
Author

cipitaua commented Mar 18, 2024

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
Copy link
Author

any hint?

@mhx
Copy link
Owner

mhx commented Mar 23, 2024

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
Copy link
Author

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

@mhx
Copy link
Owner

mhx commented Mar 24, 2024

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
Copy link
Owner

mhx commented Apr 3, 2024

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

@cipitaua
Copy link
Author

cipitaua commented Apr 3, 2024

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

@mhx
Copy link
Owner

mhx commented Apr 3, 2024

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

@mhx
Copy link
Owner

mhx commented Apr 10, 2024

Fixed in v0.9.7.

@mhx mhx closed this as completed Apr 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants