Chris Murphy posted on Thu, 10 Mar 2016 12:35:31 -0700 as excerpted: > It's a tricky problem. If you're the owner of a filesystem tree, but > something definitely not owned at all by you is buried in that tree > somewhere, to do a subvolume delete don't you have to now traverse the > entire thing to find out? Or does the owning user have sufficient > implied permission by owning the subvolume, that no matter what's in it, > is simply gone unless it's another subvolume?
Well, to the extent that subvolumes aren't special, they're supposed to behave like subdirs. So it seems simple enough to me, just use subdir permissions semantics and don't worry about it. Which means you can delete files you don't own located directly in a directory (so subvol) you have write permissions to, even if you couldn't write to the files themselves, but if those files are in turn nested in a subdir you can't write to, then you can't delete the files (even if you actually own the files and can write to them, meaning you could change them, but not delete them), and thus can't delete the dir, which means you can't delete its parent dir... or subvol. At least, that's the way it /should/ work. Unless of course subvolumes are documented to be special in that regard, since subvolumes are allowed to differ in behavior from subdirs if that's a specific feature of being a subvolume, in which case the documentation can simply document the way it works, which can be arbitrarily defined as convenient for the implementation if desired, and be done with it. Of course, if subvolumes were /not/ declared to be special in that regard, and thus were supposed to fit the subdir model, actually implementing that would involve crawling the subdir tree checking the ownership and permissions of all nested subdirs and subvols, as many layers deep as it goes, and that would need done in the foreground, before the deletion could return, which would tend to slow down the subvolume delete implementation toward that of subdir delete. So of speedy subvolume delete is to be retained, then it seems subvols need to be defined to have special subvol behavior in this regard, that does NOT follow subdir behavior, with that special behavior being defined as, if you own the subvolume, you can delete it (and its children), regardless of whether you'd have permissions to delete files in the subdirs beneath it and thus couldn't delete it were it a regular subdir. But that brings up the opposite question, or otherwise put, the same question in the other direction, as well. Currently, users can create subvols but not (ordinarily) delete them. Can they create those subvols in directories they don't have write permissions in, and thus couldn't create subdirs or files in? If so, that seems to be another security issue waiting to be exploited. If not, then even if they have ownership of the subvol itself, they shouldn't be able to delete it, if it's in a subdir they don't have write permissions in and thus couldn't create it in. Every time this sort of subvolumes permissions issue comes up, I get a (metaphorical) headache trying to sort out the permissions and thus security implications, and end up glad I'm simply not dealing with them here. Tho I can't do anything about the security implications if normal users can create them, even if my policy is not to do so. Which does have me somewhat worried, because that sort of problem is notorious for its unforeseen security implications, and right now, because any user (presumably with write permissions on any subdir on a btrfs) can create subvolumes, that means anyone running btrfs is exposed to those convoluted and likely unforeseen security issues. Which is definitely another reason not to consider btrfs fully stabilized, until that sort of thing gets sorted. Personally, I'd say just require superuser privs (and/or appropriate filecaps and/or SEL security labels) to create them as well, and avoid the whole problem. Yes, it'll be limiting, but it's a limit that will avoid the entire Pandora's box of permissions and security implications. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
