Tomasz Pala posted on Fri, 15 Dec 2017 09:22:14 +0100 as excerpted:
> I wonder how this one db-library behaves:
>
> $ find . -name \*.sqlite | xargs ls -gGhS | head -n1
> -rw-r--r-- 1 15M 2017-12-08 12:14
> ./.mozilla/firefox/vni9ojqi.default/extension-data/ublock0.sqlite
>
> $ ~/fiemap ./.mozilla/firefox/*.default/extension-data/ublock0.sqlite |
> head -n1
> File ./.mozilla/firefox/vni9ojqi.default/extension-data/ublock0.sqlite
> has 128 extents:
>
>
> At least every $HOME/{.{,c}cache,tmp} should be +C...
Many admins will put tmp, and sometimes cache or selected parts of it, on
tmpfs anyway... thereby both automatically clearing it on reboot, and
allowing enforced size control as necessary.
>> And if possible, use nocow for this file.
>
> Actually, this should be officially advised to use +C for entire /var
> tree and every other tree that might be exposed for hostile write
> patterns, like /home or /tmp (if held on btrfs).
>
> I'd say, that from security point of view the nocow should be default,
> unless specified for mount or specific file... Currently, if I mount
> with nocow, there is no way to whitelist trusted users or secure
> location, and until btrfs-specific options could be handled per
> subvolume, there is really no alternative.
Nocow disables many reasons people run btrfs in the first place,
including checksumming and damage-detection, with auto-repair from other
copies where available (raid1/10 and dup modes primarily), as well as
btrfs transparent compression, for users using that. Additionally,
snapshotting, another feature people use btrfs for, turns nocow into cow1
(cow the first time a block is written after a snapshot), since
snapshotting locks down the previous extent in ordered to maintain the
snapshotted reference.
And given that any user can create a snapshot any time they want (even if
you lock down the btrfs executable, if they're malevolent users and not
locked to only running specifically whitelisted executables, they can
always get a copy of the executable elsewhere), and /home or individual
user subvols may well be auto-snapshotted already, setting nocow isn't
likely to be of much security value at all.
So nocow is, as one regular wrote, most useful for "this really should go
on something other than btrfs, but I'm too lazy to set it up that way and
I'm already on btrfs, so the nocow band-aid is all I got. And yes, I try
using my screwdriver as a hammer too, because that's what I have there
too!"
In that sort of case, just use some other filesystem more appropriate to
the use-case, and you won't have to worry about btrfs issues, cow-
triggered or otherwise, in the first place.
--
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
