I'm not sure what the conflict is, at least format-wise. Naturally, there would need to be some work to reconcile the two patches, but my patch only alters the format for directories which are encrypted and casefolded, which always must have the additional hash field. In the case of dirdata along with encryption and casefolding, couldn't we have the dirdata simply follow after the existing data? Since we always already know the length, it'd be unambiguous where that would start. Casefolding can only be altered on an empty directory, and you can only enable encryption for an empty directory, so I'm not too concerned there. I feel like having it swapping between the different methods makes it more prone to bugs, although it would be doable. I've started rebasing the dirdata patch on my end to see how easy it is to mix the two. At a glance, they touch a lot of the same areas in similar ways, so it shouldn't be too hard. It's more of a question of which way we want to resolve that, and which patch goes first. I've been trying to figure out how many devices in the field are using casefolded encryption, but haven't found out yet. The code is definitely available though, so I would not be surprised if it's being used, or is about to be. -Daniel On Tue, Feb 9, 2021 at 8:03 PM Theodore Ts'o <tytso@xxxxxxx> wrote: > > On Tue, Feb 09, 2021 at 08:03:10PM -0700, Andreas Dilger wrote: > > Depending on the size of the "escape", it probably makes sense to move > > toward having e2fsck migrate from the current mechanism to using dirdata > > for all deployments. In the current implementation, tools don't really > > know for sure if there is data beyond the filename in the dirent or not. > > It's actually quite well defined. If dirdata is enabled, then we > follow the dirdata rules. If dirdata is *not* enabled, then if a > directory inode has the case folding and encryption flags set, then > there will be cryptographic data immediately following the filename. > Otherwise, there is no valid data after the filename. > > > For example, what if casefold is enabled on an existing filesystem that > > already has an encrypted directory? Does the code _assume_ that there is > > a hash beyond the name if the rec_len is long enough for this? > > No, we will only expect there to be a hash beyond the name if > EXT4_CASEFOLD_FL and EXT4_ENCRYPT_FL flags are set on the inode. (And > if the rec_len is not large enough, then that's a corrupted directory > entry.) > > > I guess it is implicit with the casefold+encryption case for dirents in > > directories that have the encryption flag set in a filesystem that also > > has casefold enabled, but it's definitely not friendly to these features > > being enabled on an existing filesystem. > > No, it's fine. That's because the EXT4_CASEFOLD_FL inode flag can > only be set if the EXT4_FEATURE_INCOMPAT_CASEFOLD is set in the > superblock, and EXT4_ENCRYPT_FL inode flag can only be set if > EXT4_FEATURE_INCOMPAT_ENCRYPT is set in the superblock, this is why it > will be safe to enable of these features, since merely enabling the > file system features only allows new directories to be created with > both CASEFOLD_FL and ENCRYPT_FL set. > > The only restriction we would have is a file system has both the case > folding and encryption features, it will *not* be safe to set the > dirdata feature flag without first scanning all of the directories to > see if there are any directories that have both the casefold and > encrypt flags set on that inode, and if so, to convert all of the > directory entries to use dirdata. I don't think this is going to be a > significant restriction in practice, though. > > - Ted > > > -- > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@xxxxxxxxxxx. >
