Support OCI standard dockerfile

[SwirtaB]

I have slightly changed the Dockerfile to better comply with the OCI standard so that other container engines can be used (e.g., podman).

Modifications:

1. Allow to specify USERNAME of user inside container via --build-arg
2. Add custom GID for user inside container
3. Create user without sudo permissions, enforcing fully rootless operation (inside container)
4. Delete SHELL command which is specific to Docker and update scripts to sh (only pytroch installation required changes)
5. Minor optimizations (reduced number of layers by aggregating commands)

This image can be successfully built and run with podman fully rootless, without any additional build parameters. I do not have ability to test it against docker build engine I would be grateful if one could test it. If you find this PR worth integrating I can update documentation to address deploying container in fully rootless mode.

[Zunhammer]

Hi,
thanks for the proposes changes. I can confirm that docker build works as well as running the container. However, I disagree to remove sudo as some people might want to install additional software inside the container for testing or development which requires elevated rights (e.g. apt) and without rebuilding the image all the time. IMO this is used more as a dev container so I would like to keep sudo here.

Best

[SwirtaB]

Thanks for the answer. I can bring back the ability to run sudo by the user inside the container. That said, I think that it would be beneficial (from a security standpoint) to drop skipping asking for password and allow the end user to provide its own (for example, via --build-arg) with some default clearly stated in doc if someone decided not to use this functionality. What do you think about it?
I will have some time later this week to come up with a proper solution, and I will update this PR accordingly. Should I change this PR to draft or leave it as it is?

[SwirtaB]

@Zunhammer
Hi,
I have two propositions to address your issue:

1. Force the end user to change the default password when the container is created (using the standard passwd command), done via the CMD command in Dockerfile.
2. Add non root user to sudoers and allow them to use apt install/remove/update.

The first option is quite robust, since end users have the ability to enforce security with a strong password and use sudo without restrictions. Also, by doing it via CMD, one can override this procedure and run the image as executable (as stated in doc).

The second option strives to achieve fine-grained control over user privileges, limiting them to only the necessary ones (installing, removing and updating packages from the system repo). Unfortunately, this is more prone to errors on the maintainer's side, and I think that the first one is better due to its simplicity.

What do you think?

[Zunhammer]

Hi SwirtaB,

thanks for evaluating and sharing the options. Personally, I think it's bothering to change the password on each container start which is why I would prefer the second option.

However, the main purpose (IMO) of this container is to use it for development. So, I would keep it simple and mainly easy to use at this point. People who want to use the container in areas relevant for security should adopt the Dockerfile anyway.

Looking foward to get your feedback. Would be nice to have other opinions as well :)

Best regards

[SwirtaB]

Personally, I am a strong advocate for enforcing good security practices, especially in FOSS. Nerfstudio has a lot of dependencies that are outside nerfstudio team control and can be exploited, e.g., in supply chain attacks. Ruling out such a scenario without taking any action just because it is unlikely is questionable, in my opinion. That said, I completely understand that this project isn't production-grade software but is provided as is (though with good intentions ;) ), and the end user is responsible for preventing any unwanted behaviors.

Personally, I think that changing the password on the first container run isn't that much of a problem, assuming the container is stopped and not deleted after exiting (no --rm flag). But I do understand that one can be against that behavior. So I propose three actions:

1. Add back unrestricted sudo.
2. Clearly state in the documentation that this can be exploited, so that the end user is properly informed.
3. Keep in Dockerfile commented lines that will enforce security inside the container. That way, any user who wishes to develop in a stricter environment can easily build an image without sudo permissions.

In summary, container workflow stays the same (sudo permissions), users are informed about potential dangers and can decide for themselves, and users who want to enforce best practices can do so by commenting clearly marked parts of Dockerfile and building a custom image.

I can make changes in coming week, so that there will be actual Dockerfile to look at. Many thanks for your feedback and pointing out too strict approach from my side.

That is quite the long one :)

[SwirtaB]

I have updated this PR. I brought back sudo and added ability for user to run apt-get update/upgrade/install/remove without typing password.

[SwirtaB]

@Zunhammer any thoughts?

[jb-ye]

@Zunhammer Could you follow up this PR? Does the current state look good to you?

[Zunhammer]

Hey @SwirtaB

sorry for the late reply. To me it looks good.

[SwirtaB]

No worries; I am glad I could contribute to this project.