简体   繁体   English

在已挂载的文件系统中测试 -x

[英]test -x in Mounted Filesystem

I'm using QEMU to test Raspberry Pi before putting the image onto an SD card.在将图像放入 SD 卡之前,我正在使用 QEMU 来测试 Raspberry Pi。 I'm setting up an automated script to put some files onto the Pi, among other things, so that when I put the SD card into the Pi, it is immediately usable.我正在设置一个自动脚本,将一些文件放到 Pi 上,除其他外,这样当我将 SD 卡放入 Pi 时,它可以立即使用。 I think I've run into a quirk in how permissions work, but I'm not sure.我想我在权限的工作方式上遇到了一个怪癖,但我不确定。

When you run test -x , the file is supposed to be executable.当您运行test -x时,该文件应该是可执行的。 Basically, the x bit is supposed to be on for your user.基本上, x位应该为您的用户打开。 However, this doesn't seem to apply to files inside mounted filesystems.但是,这似乎不适用于已挂载文件系统中的文件。

The host is Ubuntu, and the guest backing image is Raspberry Pi Buster.主机是 Ubuntu,来宾背景是 Raspberry Pi Buster。 I created the mountpoint with guestmount , because I was mounting a snapshot, not the original, and this seems to be the only/best way to do that.我用guestmount创建了挂载点,因为我挂载的是快照,而不是原始快照,这似乎是唯一/最好的方法。 The basic flow was:基本流程是:

qemu-img convert -Oqcow2 raspberry-pi.img raspberry-pi.qcow
qemu-img create -f qcow2 snapshot.qcow -b raspberry-pi.qcow
sudo guestmount -a 'snapshot.qcow' -i 'mountpoint/'

For example, I have a file outside the repository.例如,我在存储库之外有一个文件。 The file I'm testing inside the mountpoint was created by root, so I chmod ed this file to root for comparison:我在挂载点内测试的文件是由 root 创建的,因此我将此文件chmod编辑到 root 以进行比较:

$ sudo ls -l --author ~/test/file
-rw-r--r-- 1 root root root 1133 Oct  8 21:43 /home/me/test/file
$ sudo test -x ~/test/file && echo 'exists' || echo 'doesn\'t exist'
doesn't exist

However, for a file inside the mountpoint, with the same permissions, the test is successful:但是,对于挂载点内的文件,具有相同的权限,测试成功:

$ sudo ls -l --author mountpoint/home/pi/test/file
-rw-r--r-- 1 root root root 0 Oct  8 22:41 mountpoint/home/pi/test/file
$ sudo test -x ~/test/file && echo 'exists' || echo 'doesn\'t exist'
exists

Why is the file inside the mountpoint executable, whereas the one outside is not executable?为什么挂载点里面的文件是可执行的,而外面的文件是不可执行的? Is this because the mounted filesystem is a different architecture (x86 vs. ARM)?这是因为挂载的文件系统是不同的体系结构(x86 与 ARM)吗? Is it because I'm using guestmount , and the filesystem isn't the real filesysem, but an amalgamation of the snapshot & the original file?是不是因为我使用的是guestmount ,文件系统不是真正的文件系统,而是快照和原始文件的合并? Or is this just the way mounting works?或者这只是安装的方式? Where can I find more resources on this peculiar behavior, like other permission quirks I might encounter?我在哪里可以找到更多关于这种特殊行为的资源,就像我可能遇到的其他权限问题一样?

If you need any more information about the host or guest, please ask.如果您需要有关房东或房客的更多信息,请询问。

This is a bug in libguestfs used by guestmount .这是libguestfs使用的guestmount中的错误。 You can see it here :你可以在这里看到它

  /* Root user should be able to access everything, so only bother
   * with these fine-grained tests for non-root.  (RHBZ#1106548).
   */
  if (fuse->uid != 0) {
    [...]
    if (mask & X_OK)
      ok = ok &&
        (  fuse->uid == statbuf.st_uid ? statbuf.st_mode & S_IXUSR
           : fuse->gid == statbuf.st_gid ? statbuf.st_mode & S_IXGRP
           : statbuf.st_mode & S_IXOTH);
  }

The FS takes a shortcut saying that since you're root you have full access, so there's no point checking the permissions. FS 走捷径说因为你是 root 你有完全访问权限,所以没有必要检查权限。

As you've demonstrated, this is not true.正如您所证明的,这不是真的。 Root should only have execute permissions for directories, and for files where at least one of the execute bits is set. Root 应该只对目录和至少设置了一个执行位的文件具有执行权限。

I was unable to build the project to submit a patch, but you can file a bug.我无法构建项目以提交补丁,但您可以提交错误。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM