4 ms·

Yep, this is a common problem. The solution is not perfect, but works correctly with respect to permissions: https://medium.com/@ramangupta/why-docker-data-con

by cheez 10y ago

Yep, this is a common problem. The solution is not perfect, but works correctly with respect to permissions: https://medium.com/@ramangupta/why-docker-data-containers-are-good-589b3c6c749e#.oaw54kvjr https://medium.com/@ramangupta/why-docker-data-containers-ar...

taeric 10y ago
I'm not seeing anything there that addresses this. To be clear, as a service deployment mechanism, this is fine. As an end user tool, this blows. Unless every container builds in support for LDAP or Kerberos, then each container is effectively a new computer on the network without auth setup in a meaningful way.
- cheez 10y ago
  What it's saying is that you have a container you use only to store the data, then share that container's volume with the target container. Finally, because it's on your hard drive, you can access it. Basically, instead of host -> container, you do container -> container. And yeah, the container is supposed to be effectively a new computer, but you can build images to create the auth environments you need and base everything off those.
  - taeric 10y ago
    But that doesn't work unless you do everything with public permissions. Seriously try it. Make a container that you share a volume with. Do something in that container on some data and see who owns it according to your computer. The use case I have above is a real one. Somehow try to share your .ssh folder with a utility container sometime. User namespaces somewhat help. But fall flat for the case of "still being you" on a container. It can be comical even for the intended two containers choice. Unless both use the same uid:gid to write files, one container will not be able to read the other containers data.
    - cheez 10y ago
      So here is how I would think about your problem: am I doing this the way the tool wants me to do this? Does the tool even support this use case? If not, how should it be done? Is it impossible, or do I just not like the aesthetics of the solution? If it's just the aesthetics of the solution, then you have a way forward. But if it is literally impossible to get data on and off a container, then you have a problem.

by cheez 10y ago

taeric 10y ago

I'm not seeing anything there that addresses this. To be clear, as a service deployment mechanism, this is fine. As an end user tool, this blows. Unless every container builds in support for LDAP or Kerberos, then each container is effectively a new computer on the network without auth setup in a meaningful way.

cheez 10y ago
What it's saying is that you have a container you use only to store the data, then share that container's volume with the target container. Finally, because it's on your hard drive, you can access it. Basically, instead of host -> container, you do container -> container. And yeah, the container is supposed to be effectively a new computer, but you can build images to create the auth environments you need and base everything off those.
- taeric 10y ago
  But that doesn't work unless you do everything with public permissions. Seriously try it. Make a container that you share a volume with. Do something in that container on some data and see who owns it according to your computer. The use case I have above is a real one. Somehow try to share your .ssh folder with a utility container sometime. User namespaces somewhat help. But fall flat for the case of "still being you" on a container. It can be comical even for the intended two containers choice. Unless both use the same uid:gid to write files, one container will not be able to read the other containers data.
  - cheez 10y ago
    So here is how I would think about your problem: am I doing this the way the tool wants me to do this? Does the tool even support this use case? If not, how should it be done? Is it impossible, or do I just not like the aesthetics of the solution? If it's just the aesthetics of the solution, then you have a way forward. But if it is literally impossible to get data on and off a container, then you have a problem.