4 ms·

Can you do similar trickery to ensure `mount` doesn't list your bind mount?

by eptcyka 2y ago

duskwuff 2y ago
I don't see why not - that's just reading from /proc/mounts.
- dredmorbius 2y ago
  Nitpicking: mount reads from /proc/self/mounts, that is, the mounts as seen from that process. This is how tricks such as chroot jails work, as they present a different mount set and filesystem tree from the base system.
  - duskwuff 2y ago
    Same thing, really - /proc/mounts is a symlink to /proc/self/mounts.
    - dredmorbius 2y ago
      Fair enough, though casual readers may not realise this.
  - caf 2y ago
    chroot is a different, older system that pre-dates different mount namespaces.
    - dredmorbius 2y ago
      My understanding is that chroot presently does make use of the different mount namespaces, though I could be wrong here. How did chroot used to work in this regard? Were mountpoints outside the chroot jail itself accessible? Because if so, that ... would violate some key points of using a chroot jail in the first place. Though if chroot applied strictly to the filesystem and not mount points that might still offer benefits, and I seem to recall running into ... unexpected behaviours ... using chroots in the past.
      - LegionMammal978 2y ago
        When you create a new mount namespace, the kernel creates a copy of every mount reachable from the filesystem (as visible to the process creating it). Then, it changes the current process's root directory and current directory to point to the same paths in the corresponding mounts. Changing a process's root via chroot is otherwise a totally separate operation.
      - caf 2y ago
        The classic chroot(2) system call just changes the directory entry that's used for the root in that process. It only affects pathname resolution (including resolution of the pathnames in symbolic links). If an unconstrained uid zero process is inside the chroot but can access or create device nodes, it can mount devices within the chroot just fine.

Can you do similar trickery to ensure `mount` doesn't list your bind mount?

duskwuff 2y ago

I don't see why not - that's just reading from /proc/mounts.

dredmorbius 2y ago
Nitpicking: mount reads from /proc/self/mounts, that is, the mounts as seen from that process. This is how tricks such as chroot jails work, as they present a different mount set and filesystem tree from the base system.
- duskwuff 2y ago
  Same thing, really - /proc/mounts is a symlink to /proc/self/mounts.
  - dredmorbius 2y ago
    Fair enough, though casual readers may not realise this.
- caf 2y ago
  chroot is a different, older system that pre-dates different mount namespaces.
  - dredmorbius 2y ago
    My understanding is that chroot presently does make use of the different mount namespaces, though I could be wrong here. How did chroot used to work in this regard? Were mountpoints outside the chroot jail itself accessible? Because if so, that ... would violate some key points of using a chroot jail in the first place. Though if chroot applied strictly to the filesystem and not mount points that might still offer benefits, and I seem to recall running into ... unexpected behaviours ... using chroots in the past.
    - LegionMammal978 2y ago
      When you create a new mount namespace, the kernel creates a copy of every mount reachable from the filesystem (as visible to the process creating it). Then, it changes the current process's root directory and current directory to point to the same paths in the corresponding mounts. Changing a process's root via chroot is otherwise a totally separate operation.
    - caf 2y ago
      The classic chroot(2) system call just changes the directory entry that's used for the root in that process. It only affects pathname resolution (including resolution of the pathnames in symbolic links). If an unconstrained uid zero process is inside the chroot but can access or create device nodes, it can mount devices within the chroot just fine.