Announcement

Collapse
No announcement yet.

IDMAPPED Mounts Aim For Linux 5.12 - Many New Use-Cases From Containers To Systemd-Homed

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • IDMAPPED Mounts Aim For Linux 5.12 - Many New Use-Cases From Containers To Systemd-Homed

    Phoronix: IDMAPPED Mounts Aim For Linux 5.12 - Many New Use-Cases From Containers To Systemd-Homed

    Ahead of the Linux 5.12 merge window expected to open at end of day tomorrow, assuming Linux 5.11 is out on schedule, there is already a pending pull request with a big feature addition: IDMAPPED mounts...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    oh, please yes...
    atm i have multiple docker containers which i had to rewrite for the sole reason that the original one did not support different uids and gids (eg nextcloud)

    i hope that this will work with bind mounts and that docker will integrate it

    Comment


    • #3
      Well, this is a classic solution to a problem by adding a (nother) layer of indirection.

      Essentially, by making the owner and group of a file a random identifier, then mapping that identifier to an access ruleset, you can add all sorts of rules to the mapping process, which can be dynamic. This is the same problem as (partially) solved by ACLs.

      The fun will be in making the mapping process efficient. In a pathological worst case, every file in a file system will have a different identifier, and every user will have a different set of access permissions. It's a bit like maintaining an efficient forwarding table for IPv6 and managing a firewall rule set simultaneously. I hope it works.

      Comment


      • #4
        Originally posted by Old Grouch View Post
        Well, this is a classic solution to a problem by adding a (nother) layer of indirection.

        Essentially, by making the owner and group of a file a random identifier, then mapping that identifier to an access ruleset, you can add all sorts of rules to the mapping process, which can be dynamic. This is the same problem as (partially) solved by ACLs.

        The fun will be in making the mapping process efficient. In a pathological worst case, every file in a file system will have a different identifier, and every user will have a different set of access permissions. It's a bit like maintaining an efficient forwarding table for IPv6 and managing a firewall rule set simultaneously. I hope it works.
        Eh what? This is just a mapping. Did you read the PR summary?

        Comment


        • #5
          YAAAAAASSSSS!!

          So good for working around issues with container ownership and external disks between systems!

          Comment


          • #6
            Originally posted by flower View Post
            docker
            podman

            Comment


            • #7
              Originally posted by pal666 View Post
              > docker
              podman
              selfdock

              Actually, this isn't a problem with selfdock (at least not one caused by containerization), since as the name implies, it will only ever let you run as your own uid:gid (thus no mapping is needed for file permissions in volumes to work the same).
              Last edited by andreano; 14 February 2021, 11:50 AM.

              Comment


              • #8
                Finally. I was waiting for this feature for more than a decade.

                Comment


                • #9
                  phoronix you might like to add to your list of benefits - this allows to give user access to read-only-mounted filesystems which do support posix permissions. You can't chrown -r an ro-mounted fs!

                  ie if you have an ext3 disk image written into a zisofs written onto a BDROM backup and you want to access files from one of the users who has a different UID than your current user. In the past my workaround was to use su -c to launch thunar as the target user. That's a clumsy workaround, and requires that UID to exist locally, and could be a security risk if that UID is actually in use, and mutually un-trusting.

                  Comment

                  Working...
                  X