3 ms·

In somewhat related news, rootless Docker support is no longer an experimental feature. Has anyone used it and liked/disliked it?

xorcist 6y ago
I'd prefer podman for that use case since it's designed that way from the get go.
hardwaresofton 6y ago
I have, and it's great/you forget about it pretty quickly. I've actually gone (rootful?)docker->(rootless)podman->(rootless)docker, and I've written about it: - https://vadosware.io/post/rootless-containers-in-2020-on-arch-linux/ https://vadosware.io/post/rootless-containers-in-2020-on-arc... - https://vadosware.io/post/bits-and-bobs-with-podman/ https://vadosware.io/post/bits-and-bobs-with-podman/ - https://vadosware.io/post/back-to-docker-after-issues-with-podman/ https://vadosware.io/post/back-to-docker-after-issues-with-p... I still somewhat long after podman's lack of a daemon but some of the other issues with it currently leave it completely out for me (now that docker has caught up) -- for example lack of linking support. Podman works great outside of those issues though, you just have to be careful if it does something in a way that expects docker semantics (usually the daemon or an unix socket on disk somewhere). You'll also find some cutting edge tools like dive[0] also have some support for podman[1] but it's not necessarily the usual case. [0]: https://github.com/wagoodman/dive https://github.com/wagoodman/dive [1]: https://github.com/wagoodman/dive/issues/172 https://github.com/wagoodman/dive/issues/172
- westurner 6y ago
  podman v3 has a docker-compose compatible socket. From https://news.ycombinator.com/item?id=26107022 https://news.ycombinator.com/item?id=26107022 : > "Using Podman and Docker Compose" https://podman.io/blogs/2021/01/11/podman-compose.html https://podman.io/blogs/2021/01/11/podman-compose.html
geofft 6y ago
At $work, developers don't get root on their Linux workstations (for annoying legacy reasons that I'm sort of personally trying to fix, but the major one is NFS). We gave people rootless Docker and it seems to work pretty well for the goal of letting people try out software that's most easily packaged as a Docker container. If it seems promising we'll want to package it better, integrate it with our access control systems, etc., but rootless Docker gives users a way to evaluate whether that work is worth doing at all.
- namibj 6y ago
  How does NFS prevent the developer from getting root?
  - geofft 6y ago
    The default and oldest auth method for NFS, "sec=sys," was designed with the assumption that servers and clients are both trusted (sysadminned by the same people) and had the same set of user accounts. Servers enforce that client connections only come from privileged ports, and they trust whatever UID the client says it's using. This works in concert with the traditional UNIX restriction that only root can bind to ports under 1024, including initiating connections where the client port is under 1024. In this model, giving users root would let them su to arbitrary UIDs on the client and impersonate other users to the server. (Alternatively, it would also let them run their own NFS client on a low port and do whatever they want, too.) This does lend itself to a very simple and efficient design, since all you're doing is transmitting a single integer over the wire to identify yourself, and the whole connection is in plaintext, authenticated only by the source port. For the HPC / cluster computing use cases where NFS is popular, the efficiency and scalability of that scheme is important. There are better authentication methods (Kerberos, notably, which also adds optional encryption), and other ways to design your NFS architecture, but they're much more operationally complicated and commercial NAS devices tend to work best with the sec=sys approach. Also, public cloud NFS-as-a-service options tend to only support sec=sys (https://cloud.google.com/filestore/docs/access-control https://cloud.google.com/filestore/docs/access-control, https://docs.aws.amazon.com/efs/latest/ug/accessing-fs-nfs-permissions.html https://docs.aws.amazon.com/efs/latest/ug/accessing-fs-nfs-p..., https://docs.microsoft.com/en-us/azure/storage/files/storage-files-how-to-create-nfs-shares https://docs.microsoft.com/en-us/azure/storage/files/storage..., etc.). We are trying to figure out how to solve this, as I mentioned, but when dealing with an organization that has decades of workflows and code assuming a traditional UNIX environment with shared multi-user machines, there's no instant solution to it. (In many cases our solution is going to be to stop using NFS and use something more object-storage shaped, which will also help us move to idiomatic public-cloud designs.)

xorcist 6y ago

I'd prefer podman for that use case since it's designed that way from the get go.

hardwaresofton 6y ago

I have, and it's great/you forget about it pretty quickly. I've actually gone (rootful?)docker->(rootless)podman->(rootless)docker, and I've written about it: - https://vadosware.io/post/rootless-containers-in-2020-on-arch-linux/ https://vadosware.io/post/rootless-containers-in-2020-on-arc... - https://vadosware.io/post/bits-and-bobs-with-podman/ https://vadosware.io/post/bits-and-bobs-with-podman/ - https://vadosware.io/post/back-to-docker-after-issues-with-podman/ https://vadosware.io/post/back-to-docker-after-issues-with-p... I still somewhat long after podman's lack of a daemon but some of the other issues with it currently leave it completely out for me (now that docker has caught up) -- for example lack of linking support. Podman works great outside of those issues though, you just have to be careful if it does something in a way that expects docker semantics (usually the daemon or an unix socket on disk somewhere). You'll also find some cutting edge tools like dive[0] also have some support for podman[1] but it's not necessarily the usual case. [0]: https://github.com/wagoodman/dive https://github.com/wagoodman/dive [1]: https://github.com/wagoodman/dive/issues/172 https://github.com/wagoodman/dive/issues/172

westurner 6y ago
podman v3 has a docker-compose compatible socket. From https://news.ycombinator.com/item?id=26107022 https://news.ycombinator.com/item?id=26107022 : > "Using Podman and Docker Compose" https://podman.io/blogs/2021/01/11/podman-compose.html https://podman.io/blogs/2021/01/11/podman-compose.html

geofft 6y ago

At $work, developers don't get root on their Linux workstations (for annoying legacy reasons that I'm sort of personally trying to fix, but the major one is NFS). We gave people rootless Docker and it seems to work pretty well for the goal of letting people try out software that's most easily packaged as a Docker container. If it seems promising we'll want to package it better, integrate it with our access control systems, etc., but rootless Docker gives users a way to evaluate whether that work is worth doing at all.

namibj 6y ago
How does NFS prevent the developer from getting root?
- geofft 6y ago
  The default and oldest auth method for NFS, "sec=sys," was designed with the assumption that servers and clients are both trusted (sysadminned by the same people) and had the same set of user accounts. Servers enforce that client connections only come from privileged ports, and they trust whatever UID the client says it's using. This works in concert with the traditional UNIX restriction that only root can bind to ports under 1024, including initiating connections where the client port is under 1024. In this model, giving users root would let them su to arbitrary UIDs on the client and impersonate other users to the server. (Alternatively, it would also let them run their own NFS client on a low port and do whatever they want, too.) This does lend itself to a very simple and efficient design, since all you're doing is transmitting a single integer over the wire to identify yourself, and the whole connection is in plaintext, authenticated only by the source port. For the HPC / cluster computing use cases where NFS is popular, the efficiency and scalability of that scheme is important. There are better authentication methods (Kerberos, notably, which also adds optional encryption), and other ways to design your NFS architecture, but they're much more operationally complicated and commercial NAS devices tend to work best with the sec=sys approach. Also, public cloud NFS-as-a-service options tend to only support sec=sys (https://cloud.google.com/filestore/docs/access-control https://cloud.google.com/filestore/docs/access-control, https://docs.aws.amazon.com/efs/latest/ug/accessing-fs-nfs-permissions.html https://docs.aws.amazon.com/efs/latest/ug/accessing-fs-nfs-p..., https://docs.microsoft.com/en-us/azure/storage/files/storage-files-how-to-create-nfs-shares https://docs.microsoft.com/en-us/azure/storage/files/storage..., etc.). We are trying to figure out how to solve this, as I mentioned, but when dealing with an organization that has decades of workflows and code assuming a traditional UNIX environment with shared multi-user machines, there's no instant solution to it. (In many cases our solution is going to be to stop using NFS and use something more object-storage shaped, which will also help us move to idiomatic public-cloud designs.)