Unprivileged containers with PRoot about mentoring HOT 8 CLOSED

Hi Lucas,

6th semester of my undergraduate program started yesterday, and we have a heavier curriculum and 2 course projects which are more demanding than I expected. I am afraid I will not be able to proceed with this proposal with college occupying lot of my time. I was parallely working on another proposal related to Dart project, and in the remaining time I will be trying my luck with that.

I hope that wasn't impolite. English isn't my first language.

from mentoring.

Hi, I am a student from Bangalore, India. I tinkered a little with PRoot (as well as fakechroot/fakeroot) around 3 years ago, it was to run debian CLI on an Android 5 phone :).

This proposal seemed interesting. I am curious whether there is a specific use case for this, however, because user namespace for rootless container seems to have become common these days.

from mentoring.

PRoot is a general purpose tool. However, there are two main use cases that I've seen:

• Running software as a user on super computer (academic) infrastructure
• Android (Usually Termux)

I think adding support for OCI containers would increase productivity for PRoot users, since they wouldn't need to manually find and download/setup their own rootfs images. However, since this is implemented as an extension, we would end up with support for both.

from mentoring.

Thanks for the perspective. I guess it can also be used to create build environments, depending on overhead of proot itself.

OCI Spec seems quite big, which parts are left to implement?

from mentoring.

Thanks for the perspective. I guess it can also be used to create build environments, depending on overhead of proot itself.

We're actually doing that here with the PRoot multiarch binaries: https://gitlab.com/proot/proot-static-multiarch

OCI Spec seems quite big, which parts are left to implement?

To be honest, I'm not sure how rootless-containers relates to the OCI specification. It might be good to document that as part of a research step in your proposal.

from mentoring.

I am looking at OCI runtime spec.

On surface it seems:

• OCI specifies some additional commands like kill and query state, which runrootless currently lacks, and container management operations like pull and delete.
• OCI config defines many options including hooks, number of them are not practical to implement on proot and few while possible, not yet implemented.

runrootless run --help shows all options supported by runc. In fact these are handled by runc command.

seeing ToRootlessSpec in vendored library specconv 1 , it took OCI runtime config, and removed some options not meaningful for rootless container. Some of them we may be able to implement with proot. But it should be worth for target use case or it will be pointless.

This is just what I guess from surface, I guess it will involve implementing some missing features, before that we will have to evaluate which of the features are relevant to use case. And then testing.

from mentoring.

This is great. I think you're moving in the right direction.

OCI specifies some additional commands like kill and query state, which runrootless currently lacks, and container management operations like pull and delete.

I think we need to clarify the scope for A) PRoot and B) Our potential GSoC project.

I don't think we need to re-implement container management (pull/push/etc.) in PRoot. We can use something like img for that, (See: https://github.com/genuinetools/img/#usage).

But I am curious how we would kill/query a running instance. As of now, we would use ps aux | grep proot and then kill -9 $(pgrep proot) or something like that.

OCI config defines many options including hooks, number of them are not practical to implement on proot and few while possible, not yet implemented.

The hooks seem interesting... perhaps if we have time, we could implement that using the Python extension for PRoot?

Definitely not an essential feature though.

seeing ToRootlessSpec in vendored library specconv 1 , it took OCI runtime config, and removed some options not meaningful for rootless container. Some of them we may be able to implement with proot. But it should be worth for target use case or it will be pointless.

This is just what I guess from surface, I guess it will involve implementing some missing features, before that we will have to evaluate which of the features are relevant to use case. And then testing.

Yes, exactly. We might want to compile a list and then work through each to determine if it is essential.

I want PRoot to be a small tool. The primary use-case is being able to re-use OCI-compatible container images in a convenient way. And since this is an extension, we should still be able to compile and use PRoot without it.

from mentoring.

No worries. Best of luck in your schooling and in GSoC!

from mentoring.