RFC: consider renaming the project (runROOTLESS -> runFULLYROOTLESS?)

[AkihiroSuda]

The current project name runROOTLESS is confusing because the upstream runc supports rootless as well but in a different way.

RFC

cc @cyphar

[cyphar]

So, the original idea I had for rootless containers was that you had no privileges at all when trying to operate with containers. The current way we are pushing forward (using newuidmap) is somewhat of a separate thing (from the usecase I originally had) -- though obviously slirp4netns is one of the things I really wanted us to have since it is also similarly unprivileged.

I would suggest this be called "fullyrootless" or something like that. The original idea behind using a different word than "unprivileged" (which I know the LXC folks were slightly annoyed by me doing) was to avoid confusion and that "rootless" had a very specific meaning. Unfortunately it looks like this idea has slightly failed because slowly we've been focusing more on usecases where you have some privilege (or you ask your admin to do something -- which I consider to be a privileged operation).

I would argue that what we are currently calling "rootless containers" is actually "unprivileged containers", very similar in concept to LXC and I think that distinguishing the two makes very little sense -- especially since now we'd need to come up with a new term to refer to what I originally referred to as "rootless containers".

[AkihiroSuda]

especially since now we'd need to come up with a new term to refer to what I originally referred to as "rootless containers".

"single-mapping" or "mapless"? still confusing though..

[cyphar]

I think that "single-mapping" is missing the point (rootless was about a more general idea of "no privileges at any point and no privileged setup"), and that "mapless" would be incorrect. I'd still argue that we should stop referring to what we currently call "rootless" as "rootless" and instead use the term "unprivileged" which is what LXC calls their efforts (which are very similar in almost every respect except for not using slirp4netns -- which is an implementation detail that I'd argue you could fairly easily swap out).