On Wed, Mar 9, 2016 at 4:45 PM, Marc MERLIN <m...@merlins.org> wrote: > On Wed, Mar 09, 2016 at 02:21:26PM -0700, Chris Murphy wrote: >> > I have a very stripped down docker image that actually mounts portion of >> > of my root filesystem read only. >> > While it's running out of a btrfs filesystem, you can't run btrfs >> > commands against it: >> > 05233e5c91f0:/# btrfs fi show >> > 05233e5c91f0:/# btrfs subvol list / >> > ERROR: can't perform the search - Operation not permitted >> > 05233e5c91f0:/# btrfs subvol list . >> > ERROR: can't perform the search - Operation not permitted >> > >> > I didn't do anything special, it's just working that way. >> >> Yep, you're not using --privileged in which case you can't list >> things. But I'm not sure what the equivalent is off hand with >> systemd-nspawn containers, I think those may always be privileged? > > Ok, cool. I just used docker out of the box, glad to know it errs on > the secure side by default. > (and I don't have systemd, so that may also help me there) >
I'm sure the default capability list for systemd-nspawn and docker is different. I know that you can tune nspawn to give the container whatever capabilities you want it to. In general though a general warning is that linux containers are still not quite 100% secure when root is running inside. Obviously the fewer capabilities you give them the better, but the level of isolation isn't quite to VM levels. It is better than chroot levels, however. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
