On Wed, Sep 25, 2019 at 08:07:12AM -0400, Colin Walters wrote: > > > On Wed, Sep 25, 2019, at 3:11 AM, Dave Chinner wrote: > > > > We're talking about user data read/write access here, not some > > special security capability. Access to the data has already been > > permission checked, so why should the format that the data is > > supplied to the kernel in suddenly require new privilege checks? > > What happens with BTRFS today if userspace provides invalid compressed > data via this interface? Then the filesystem returns EIO or ENODATA on read because it can't decompress it. User can read it back in compressed format (i.e. same way they wrote it), try to fix it themselves. > Does that show up as filesystem corruption later? Nope. Just bad user data. > If the data is verified at write time, wouldn't that be losing most of the speed advantages of providing pre-compressed data? It's a direct IO interface. User writes garbage, then they get garbage back. The user can still retreive the compressed data directly, so the data is not lost.... > Ability for a user to cause fsck errors later would be a new thing > that would argue for a privilege check I think. fsck doesn't validate the correctness of user data - it validates the filesystem structure is consistent. i.e. user data in unreadable format != corrupt filesystem structure. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
