Linux-FSCrypt Archive on lore.kernel.org
 help / color / Atom feed
From: Andreas Dilger <adilger@dilger.ca>
To: Eric Biggers <ebiggers@kernel.org>
Cc: linux-ext4 <linux-ext4@vger.kernel.org>, linux-fscrypt@vger.kernel.org
Subject: Re: [PATCH 1/4] tune2fs: prevent changing UUID of fs with stable_inodes feature
Date: Tue, 7 Apr 2020 10:18:55 -0600
Message-ID: <74B95427-9FB1-4DF8-BE75-CE099EA3A9A3@dilger.ca> (raw)
In-Reply-To: <20200407053213.GC102437@sol.localdomain>


[-- Attachment #1: Type: text/plain, Size: 2576 bytes --]


> On Apr 6, 2020, at 11:32 PM, Eric Biggers <ebiggers@kernel.org> wrote:
> 
> On Wed, Apr 01, 2020 at 08:19:38PM -0600, Andreas Dilger wrote:
>> On Apr 1, 2020, at 2:32 PM, Eric Biggers <ebiggers@kernel.org> wrote:
>>> 
>>> From: Eric Biggers <ebiggers@google.com>
>>> 
>>> The stable_inodes feature is intended to indicate that it's safe to use
>>> IV_INO_LBLK_64 encryption policies, where the encryption depends on the
>>> inode numbers and thus filesystem shrinking is not allowed.  However
>>> since inode numbers are not unique across filesystems, the encryption
>>> also depends on the filesystem UUID, and I missed that there is a
>>> supported way to change the filesystem UUID (tune2fs -U).
>>> 
>>> So, make 'tune2fs -U' report an error if stable_inodes is set.
>>> 
>>> We could add a separate stable_uuid feature flag, but it seems unlikely
>>> it would be useful enough on its own to warrant another flag.
>> 
>> What about having tune2fs walk the inode table checking for any inodes that
>> have this flag, and only refusing to clear the flag if it finds any?  That
>> takes some time on very large filesystems, but since inode table reading is
>> linear it is reasonable on most filesystems.
> 
> I assume you meant to make this comment on patch 2,
> "tune2fs: prevent stable_inodes feature from being cleared"?
> 
> It's a good suggestion, but it also applies equally to the encrypt, verity,
> extents, and ea_inode features.  Currently tune2fs can't clear any of these,
> since any inode might be using them.
> 
> Note that it would actually be slightly harder to implement your suggestion for
> stable_inodes than those four existing features, since clearing stable_inodes
> would require reading xattrs rather than just the inode flags.
> 
> So if I have time, I can certainly look into allowing tune2fs to clear the
> encrypt, verity, extents, stable_inodes, and ea_inode features, by doing an
> inode table scan to verify that it's safe.  IMO it doesn't make sense to hold up
> this patch on it, though.  This patch just makes stable_inodes work like other
> ext4 features.

Sure, I'm OK with this patch, since it avoids accidental breakage.

One question though - for the data checksums it uses s_checksum_seed to generate
checksums, rather than directly using the UUID itself, so that it *is* possible
to change the filesystem UUID after metadata_csum is in use, without the need
to rewrite all of the checksums in the filesystem.  Could the same be done for
stable_inode?

Cheers, Andreas






[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 873 bytes --]

  reply index

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-01 20:32 [PATCH 0/4] e2fsprogs: fix and document the " Eric Biggers
2020-04-01 20:32 ` [PATCH 1/4] tune2fs: prevent changing UUID of fs with " Eric Biggers
2020-04-02  2:19   ` Andreas Dilger
2020-04-07  5:32     ` Eric Biggers
2020-04-07 16:18       ` Andreas Dilger [this message]
2020-04-08  3:11         ` Eric Biggers
2020-04-10 11:53           ` Andreas Dilger
2020-04-10 15:06             ` Theodore Y. Ts'o
2020-04-10 16:30             ` Eric Biggers
2020-04-01 20:32 ` [PATCH 2/4] tune2fs: prevent stable_inodes feature from being cleared Eric Biggers
2020-04-01 20:32 ` [PATCH 3/4] ext4.5: document the stable_inodes feature Eric Biggers
2020-04-01 20:32 ` [PATCH 4/4] tune2fs.8: " Eric Biggers
2020-04-02  2:12   ` Andreas Dilger
2020-04-07  5:10     ` Eric Biggers
2020-04-10 15:24 ` [PATCH 0/4] e2fsprogs: fix and " Theodore Y. Ts'o
2020-05-07 18:18   ` Eric Biggers
2020-06-15 22:22     ` Eric Biggers
2020-07-27 16:45       ` Eric Biggers
2020-09-01 16:19         ` Eric Biggers
2020-09-21 22:41           ` Eric Biggers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=74B95427-9FB1-4DF8-BE75-CE099EA3A9A3@dilger.ca \
    --to=adilger@dilger.ca \
    --cc=ebiggers@kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-FSCrypt Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lkml.kernel.org/linux-fscrypt/0 linux-fscrypt/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-fscrypt linux-fscrypt/ https://lkml.kernel.org/linux-fscrypt \
		linux-fscrypt@vger.kernel.org
	public-inbox-index linux-fscrypt

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fscrypt


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git