On 2015-11-27 03:02, Duncan wrote: >>> Then there's the security angle to consider. With the (basically, >>> possibly modified as I suggested) flat layout, mounting something >>> doesn't automatically give people in-tree access to nested subvolumes >>> (subject to normal file permissions, of course), like nested layout >>> does. And with (possibly modified) flat layout, the whole subvolume >>> tree doesn't need to be mounted all the time either, only when you're >>> actually working with subvolumes. > >> Uhm, I don't get the big security advantage here... whether nested or >> manually mounted to a subdir,... if the permissions are insecure I'll >> have a problem... if they're secure, than not. > > Consider a setuid-root binary with a recently publicized but patched on > your system vuln. But if you have root snapshots from before the patch > and those snapshots are nested below root, then they're always > accessible. If the path to the vulnerable setuid is as user accessible > as it likely was in its original location, then anyone with login access > to the system is likely to be able to run it from the snapshot... and > will be able to get root due to the vuln. > > On a flat layout, a snapshot with the vuln would have to be mounted > before it could be accessed, as otherwise it'd be outside the mounted > tree.
Talking about security: If you split the "var" parts from the root, you get a nice side-effect that the generation of the root subvolume does not change until you update your system (e.g. by installing/updating packages). Consider this setup: 5 | +--root (subvol) | | | +--var (subvol, or mounted) | +--tmp (subvol, or tmpfs) | +--run (subvol, or tmpfs) | +--home (subvol, or mounted) | +--snapshots (dir, uid=root,mode=700) | +--root.20150101 +--root.20150102 +--... Now if you take a look at the output of "btrfs sub list -c /", you can see exactly when your root subvolume has changed. This means if you always create a new snapshot of "root" after you update your system, you are able to spot changes to the system easily: # btrfs sub list -c / ID 100 gen 4242 cgen 50 top level 5 path root ID 101 gen 4500 cgen 53 top level 5 path var [...] ID 5000 gen 4111 cgen 4111 top level 5 path snapshots/root.20151203 ID 5001 gen 4242 cgen 4242 top level 5 path snapshots/root.20151205 [...] In this example, I can see that "root" has not been altered since 20151205, as "cgen" of the snapshot matches the "gen" of the root subvolume. This is the last time I updated this system. If the "gen" of the root subvolume would be greater than 4242, I know some changes were made to the system root, and I can start tracking it down using "btrfs subvol find-new". -- 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
