Austin S. Hemmelgarn posted on Wed, 09 Mar 2016 07:15:36 -0500 as excerpted:
> On 2016-03-08 16:28, Chris Murphy wrote: >> Yes, it's a bit peculiar I can create subvolumes and snapshot them, but >> can't 'btrfs sub list/show' >> >> It's an open question why the user needs a subvolume, but I'm not >> thinking of a human user necessarily but rather some service, maybe >> it's httpd. Or maybe with the xdg-app stuff the Gnome folks are working >> on it makes sense to encapsulate applications and their updates in >> their own subvolume. *shrug* I'm open to the idea that the use case >> needs to be more compelling and detailed in order to get the >> implementation right. >> > It's probably worth tossing out there that I use them on a regular basis > as a normal user (not root or some service) for: > 1. Local copies of VCS repositories. > 2. Build directories. > 3. Staging areas for a variety of things. > 4. Specifically isolating certain parts of my home directory from > backups. > > 1-3 are mostly because of the fact that deleting a subvolume is insanely > fast compared to recursive deletion of a directory, although 4 is > somewhat significant for those as well. For #2 and possibly #3, depending on what's being staged and why, tmpfs works well, and deleting should be even faster (AFAIK, subvolume deletion returns immediately but the work continues in the background, so if you're running other IO-bound jobs they'll still be affected even tho the subvolume deletion command has returned... if it's all in memory as is tmpfs, that problem's eliminated too), tho of course you need enough memory so that tmpfs doesn't trigger swap-thrashing. But #1 and #4 of course don't work as well on tmpfs as you'll likely want them around longer, and all four cases definitely make use of the the fact that nested subvolumes wall off snapshotting and thus btrfs send, for backup purposes. And of course if you're on a limited-memory machine and thus can't easily use tmpfs for building and other staging, and don't need to care about the ongoing background IO, using subvolumes for #2 and 3 remains useful, as well. > In general I can see them being useful for any number of things from a > service perspective, although I feel that snapshots are likely more > useful there (the ability to atomically save the state of a set of files > is extremely useful for a lot of things). I consider the current situation somewhat of a security (DoS) issue, since users (or runaway scripts or malware) can create unlimited subvolumes as an ordinary user, with that user then not being able to delete them, requiring admin intervention to do so. Of course as long as it's a single-human-user with an admin-rights alter-ego login, it's not /that/ much of a security issue, but I could see it being one for human users who do not have that admin-rights alter-ego login. So were I to be running in such a situation, I'd probably use the mount option to let the users delete their own subvolumes, unless of course that opens up other security issues I'm not aware of. IMO before btrfs can really be considered stable, this possible DoS needs resolved by making the list/delete set the exact same as the create set, either by giving users some way to deal with (only) their own subvolumes just as they can their own directories, or by reserving subvolume creation to superuser, because that's what's needed for listing and deletion. Because if not, I fear someone's going to take advantage of it in some way, perhaps, as with many DoS vulns, using it to deny critical resources as a way to simplify some other more critical attack, and it'll be in the headlines as an attack that worked and a zero-day that still works. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
