Subtle errors when running from inside a chroot #59
Comments
|
are you running fuse-overlayfs as root? How did you configure the chroot? |
|
Hey giuseppe, apparently I am mistaken, this has nothing to do with running it inside a chroot, but seems to be due unsupported operations: This are the That last one only happens sometimes, pacman than complains with Here is how So in conclusion when running as user, some operations seem not to be supported. So I am actually happy this bug is not what I initially thought and apparently more of a question of which system calls are supported and which are not :-) Cheers, |
|
@ihucos are you using a user namespace for running fuse-overlayfs? That is required for gaining the capabilities for writing these xattrs. Also, another thing to try is not use tmpfs as the underlying storage. That could be the problem you are seeing |
Yes, I actually am.
I did not know that. But actually the underlying storage is in the home directory. Hmmm...
|
|
currently ioctl are not supported. We could start adding them, for example: diff --git a/main.c b/main.c
index 717b296..711bd7b 100644
--- a/main.c
+++ b/main.c
@@ -3713,6 +3713,29 @@ ovl_fsync (fuse_req_t req, fuse_ino_t ino, int datasync, struct fuse_file_info *
fuse_reply_err (req, ret == 0 ? 0 : errno);
}
+static void
+ovl_ioctl (fuse_req_t req, fuse_ino_t ino, int cmd, void *arg,
+ struct fuse_file_info *fi, unsigned flags,
+ const void *in_buf, size_t in_bufsz, size_t out_bufsz)
+{
+ int ret, res;
+ switch (cmd)
+ {
+ case FS_IOC_GETFLAGS:
+ case FS_IOC_SETFLAGS:
+ ret = ioctl (fi->fh, cmd, &res);
+ if (ret < 0)
+ fuse_reply_err (req, errno);
+ else
+ fuse_reply_ioctl (req, res, NULL, 0);
+ break;
+
+ default:
+ fuse_reply_err (req, ENOSYS);
+ break;
+ }
+}
+
static struct fuse_lowlevel_ops ovl_oper =
{
.statfs = ovl_statfs,
@@ -3745,6 +3768,7 @@ static struct fuse_lowlevel_ops ovl_oper =
.link = ovl_link,
.fsync = ovl_fsync,
.flock = ovl_flock,
+ .ioctl = ovl_ioctl,
};
static intalthough I think we should not compare to overlay in the kernel, as it runs with different privileges. Could you try that patch if it makes any difference on your kernel? |
|
That makes it different, I can't judge if better or worse: At least for my use case it's generally working, which means that pacman does install the package. I don't know if there is some kind of "standard" of which filesystem operations are expected to work and for example package managers can live with without failing. Maybe it makes sense to document what operations are not supported by unprivileged fuse-overlayfs. The best thing is of course to just fix these things. At least as previously posted, with Here is just in case how to reproduce |
|
are you able to do something like: |
|
Unfortanly not Some System information EDIT: |
|
thanks for trying it out. So the unprivileged user cannot use chattr, even when in a user namespace. If the unprivileged user now gained that capability when using overlay from the kernel, then it looks like a security issue. AFAICS, unionfs-fuse just ignore errors on the ioctl, could you confirm that if you try So I think the most correct behaviour is the one showed by fuse-overlayfs with the patch I've proposed, if an user is not able to change the inode attrs then it must be reported as an error. We could probably circumvent the issue by writing down the value in a xattr when the ioctl fails, it won't be portable but at least will work on the same fuse-overlayfs file system. |
Closes: containers#59 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
|
I've cleaned up the patch and opened #61 There is no xattr emulation done, but it enables reading inode attributes, and setting them when running as root (on the host) |
Closes: containers#59 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
When trying to run fuse-overlayfs from inside a chroot, there are hard to pin down, subtle errors.
This is some output of installing firefox inside arch linux with pacman.
When using apt, there are errors about failed GPG checks, that I can not reproduce, it's kind of difficult to pin down.
This is interesting for nested containers. With
unionfs-fuseI also get apparently the same kind of error: rpodgorny/unionfs-fuse#84 . But much more often.Let me know if I should try to find an reproducible example or give me some direction to investigate.
The text was updated successfully, but these errors were encountered: