Summary: Arch Linux is one of the few, if not the only distribution that still disables or restricts the use of unprivileged user namespaces, a feature that is used by many applications and containers to provide secure sandboxing. There have been request to turn this feature on since Linux 3.13 (in 2013) but they are still being denied. While there may have been some reason for doing so a few year ago, leading to many distributions like Debian and Red Hat to restrict its use to privileged users via a kernel patch (they never disabled it completely), today arch seems to be the only distribution to block this feature. Even conservative distros like Debian 8 and 9 have this feature fully enabled. I would like to suggest that arch stops to disable this feature in future kernel versions. Resoning: The original reason to block user namespaces were a number of security issues that allowed unprivileged users to access features they should not have access to. Due to the nature of user namespaces to provide isolated user environments with access to privileged features like other namespaces (inside that isolated namespace only), it should be obvious that this feature had to be designed carefully in order not to harm the security outside the namespace. Even though there have been issues, this feature is now considered stable enough for distros like debian and red hat to allow its use even for unprivileged users. Moreover there are many applications that use this feature to provide or enhance security Among them are: lxc, systemd-nspawn, docker, flatpak, bubblewrap, firejail, firefox, chromium After working with sandboxing applications for several month, it seems clear to me that disabling user namespaces decreases the security of the system significantly. Some of these applications can not provide core features due to user namespaces missing. Others have significant security features disabled for this reasons. But the worst part is how some of these projects dealt with the missing feature: Many are using suid bits to execute the application as root to get access to the features they would have inside a user namespace. And for those who have worked with suid applications and their security it will not be surprising that they have failed to do this securely, leading to not just a few local root exploits. Taking firejail just as an example: (CVE-2017-5207) (CVE-2017-5206) (CVE-2017-5180) (CVE-2016-10122) (CVE-2016-10118) (CVE-2016-9016) And that is just from the last release... non of these issues would have been possible if user namespaces could be used, which is btw. what bubblewrap does if the feature is available, but since it isn’t on arch they have to use suid too (but bubblewrap is designed with security in mind for a change, so no known issues so far) Chromium is another case that has to use suid to use its sandbox and while I consider the developers very skilled in regards to security (they build a very nice broker architecture sandbox on windows too) there have been local root exploits in the linux version of chromium because of this. Even while looking at the surface of this problem it becomes clear this causes way more problems then it solves. Considering arch will be or already is the only linux distribution to disable this feature, developers of future applications will have to chose between dropping support for arch or to keep using features like suid that pose a real security threat opposite to user namespaces. Therefore I urge the people responsible to reconsider their choice an enable user namespaces in future kernel versions of arch linux. Bug reports regarding user namespaces: https://bugs.archlinux.org/task/36969 https://bugs.archlinux.org/task/49337