Stéphane Graber, a longtime maintainer of LXC and LXD container projects, writes about Linux containers and his work at Canonical.
HN links it for the LXD re-licensing under AGPLv3 with a CLA and his resignation from Canonical, plus LXC security and unprivileged container posts.
> my understanding is that if you sign a CLA, you typically give a right to relicence to the beneficiary of the CLA.
Just to clarify, this depends upon the exact CLA you sign. Canonical's CLA (CCLA) [1] for example, contains this clause in Section 2.3 Outbound license:
> We may license the Contribution under any licence, including copyleft, permissive, commercial, or proprietary licences. As a condition on the exercise of this right, We agree to also license the Contribution under the terms of the licence or licences which We are using for the Material on the Submission Date.
This means that they promise to release your contribution under the original license as well. Or in other words, they won't relicense the old contributions retroactively. There may be other CLAs that don't make this promise. It's generally a good idea to read and understand what you are signing up for. (Applicable for any agreements, not just CLAs, since your argument is to avoid them.)
Almost all CLAs let the contributor retain the copyright. (If I understand correctly, copyright transfers are involved only in CAAs.) So that option is also available for you to do whatever you want to do with your contributions. In any case, the actual problem is the breach of an unwritten trust you place in the project owners. Since you generously contributed your work to them and everyone else, you'd expect the same favor in return for the contributions by others in the future. But CLAs leave that open and under…
> https://github.com/zabbly/incus/issues/89#issuecomment-30764...
> I mean sure, it's the UI component only, and not on the lxc repo but the Zabbly one, and maybe they treat things widely differently depending.
This one is fair since Incus and Zabbly have had no desire to reimplement a web UI, they've instead opted to leave that to the community resulting in LXConsole for example.
Zabbly, for additional context, is Stephane Graber's company that he set up as a consultant service for Linux and Linux Container (both in terms of the Linux Container organization and the LXC project)
As a whole, the project has left the choice of web interface up to the user: https://discuss.linuxcontainers.org/t/incus-6-7-has-been-released/22099
> But it's the same developer for both, and I'm willing to bet it's a similar mindset for projects.
This is getting dangerously close to a mischaracterization of events surrounding the Linux Containers and Canonical split.
See: https://stgraber.org/2023/12/12/lxd-now-re-licensed-and-under-a-cla/ in addition to: https://linuxcontainers.org/incus/announcement/
EDIT: I read this part to suggest that former LXD team members that are now on the Incus team potentially have the same mindset, if this is wrong, please correct me.
> And I swear I had a similar experience with regards to some other incus issues where there was a similar response about changes.
So far from my two years of interaction (both as a lurker and commenter) on the forums and…
I've also struggled with the distinction, but I believe the commenter above was referring to LXC (and LXD's) "system containers".
Full user namespacing has been in from very early on (day 1?) which is the "increased security" -- this is where I believed the difference between "system containers" for LXC and regular "application containers" was. runc was not always the runtime underneath Docker, and IIRC it has not always had support for proper user namespacing for as long as LXC has.
Also, LXC has so many more features packed in I think it's a disservice to compare it to runc in the first place.
It should go without saying but I would absolutely love for you to sprinkle some knowledge on me wherever I'm wrong about either of these.
[EDIT] - Getting downvotes so figured maybe I said something egregious so I did some digging:
- LXC had user namespaces @ v1.0 in 2013[0]
- Docker got user namespaces @ 1.10 in 2016[1]
This is the distinction I meant.
[0]: https://stgraber.org/2014/01/01/lxc-1-0-security-features/
[1]: https://blog.docker.com/2016/02/docker-1-10/
Can someone talk about LXC security in practice?
I've read[1], and it is excellent to have options, but there I'd like guidance for what is actually usable and useful, especially via Docker.
Background: I want to be able to execute arbitrary code submitted from the web. At the moment I'm sandboxing it inside a ZeroVM[2] container, inside a Docker (LXC) container.
I'd like to lock down the Docker container more than the default (eg, disable outgoing network connections), but I don't really know where to start.
(And yes, I do find it strange that it was easier to get an entirely new, experimental and undocumented container running inside LXC than it was to work out how to configure LXC. But layers are good, right?)
[1] https://www.stgraber.org/2014/01/01/lxc-1-0-security-features/
[2] http://zerovm.org/
My understanding is that recent (13.10+) Ubuntu ships with an AppArmor profile that blocks known ways of escalating out of the container. So, LXC under Ubuntu is in better shape than LXC on other distros, where you can use the uevent_helper trick[1] to easily escape the container.
It sounds like your use case could also use the new unprivileged containers[2] feature, which is going to be a dramatic increase in security (since even if you somehow get access to run a command on the host container, it would not be as root).
[1]: http://blog.bofh.it/debian/id_413
[2]: https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/
The link in the parent post is probably the best source, particularly the line:
> While the team behind Linux Containers regrets that decision and will be missing LXD as one of its projects, it does respect Canonical’s decision
That team includes Stéphane Graber who was for years the project lead for LXD, and a highly-visible evangelist for the project, producing videos[1] every couple weeks and answering questions on the forum[2].
He quit Canonical a few days after this announcement[3].
[1]: https://www.youtube.com/@LXD/videos
[2]: https://discuss.linuxcontainers.org
[3]: https://stgraber.org/2023/07/10/time-to-move-on/