Re-introduce support for EXT4_IOC_GET_ENCRYPTION_PWSALT and iterating over mtab

[Flowdalic]

I am very curious why support for the EXT4_IOC_GET_ENCRYPTION_PWSALT ioctl() and the iteration routine over mtab was removed.

After reading some e2fsprogs and linux kernel source, it appears the idea of e4crypt is to store the salt in the superblock of the ext4 filesystem, in an effort to become more "user-friendly" (see https://github.com/tytso/e2fsprogs/commit/41f2210131cfbaa4059cebae3a9b0f104fe89f70). And this appears sensible to me. And while pam_e4crypt once had support for the EXT4_IOC_GET_ENCRYPTION_PWSALT ioctl() which returns the (per ext4 filesystem) salt, it was removed with #27. Furthermore, iterating over all filesystem entries in mtab was removed with #25.

I can not think of a good reason, especially since ext4 appears to be moving towards storing the salt in the filesystem superblock. And if pam_e4crypt would simply create a policiy (key+salt) for every ext4 filesystem in mtab, then the usage of pam_e4crypt would become much easier.

Slightly related side-node: pam_e4crypt's README currently stats that "Users must provide a salt (up to 16 bytes)". This is not entirely correct, e4crypt is able to handle salts of much larger sizes. Only the salt stored in the superblock and returned by the ioctl() is 16 bytes in size.

Would you accept patches that re-introduce EXT4_IOC_GET_ENCRYPTION_PWSALT and iterating over mtab?

[neithernut]

In cases with multiple ext4 (with encryption enabled) mounted, we could potentially choose the "wrong" salt, i.e. a salt originating from from another FS than the one containing a specific encrypted directory. In the worst case, the salt used for setting up an encrypted home could originate from an external hard drive, rendering it inaccessible if the drive is not present. We thus deemed using an explicit salt would be more robust and less confusing for users with multiple ext4 mounts.

I definitely should have documented this more clearly somewhere (preferably in some merge/commit message).

Would you accept patches that re-introduce EXT4_IOC_GET_ENCRYPTION_PWSALT and iterating over mtab?

Only on the following conditions:

• the user should be able to choose the FS from which the salt is retrieved
• for setup, the e4crypt tool should also allow you to make this choice (it's been a long time and my memory is hazy, but I don't remember such an option)
• using the ioctl call should be disabled by default (at least for the time being)

Slightly related side-node: pam_e4crypt's README currently stats that "Users must provide a salt (up to 16 bytes)". This is not entirely correct, e4crypt is able to handle salts of much larger sizes. Only the salt stored in the superblock and returned by the ioctl() is 16 bytes in size.

e4crypt may not have this limitation (any more), but pam_e4crypt (stll) has.

---

Please take note that I'm quite tardy when it comes to do my job as a maintainer. I intended to work on this more for a long time now, particularly to set up some proper tests, but somehow I always got stuck on some minor detail. Hence I may be quite slow or even reluctant to incorporate new changes. In fact some changes already started piling up. So... be warned that at the moment, working on this may turn out to be rather frustrating for you.

[Flowdalic]

In cases with multiple ext4 (with encryption enabled) mounted, we could potentially choose the "wrong" salt, i.e. a salt originating from from another FS than the one containing a specific encrypted directory.

That can't happen if you simply create keys/policies for every ext4 filesystem on login. Or am I missing something? If not, then simply iterating over mtab and inserting a key generatied with every ext4 superblock-salt should do the trick.

• the user should be able to choose the FS from which the salt is retrieved

See above: I do not think this is necessary. And if it is indeed not necessary, then there is one less option to ask the user, which is always good.

e4crypt may not have this limitation (any more), but pam_e4crypt (stll) has.

I don't think so: pam_e4crypt currently uses EXT4_MAX_SALT_SIZE, which is defined, at least on my system, in /usr/include/ext2fs/ext2_fs.h to 256.

[neithernut]

That can't happen if you simply create keys/policies for every ext4 filesystem on login. Or am I missing something? If not, then simply iterating over mtab and inserting a key generatied with every ext4 superblock-salt should do the trick.

Yes, it is possible to just create policies for all ext4 file systems present. However, you encrypt a directory with a specific policy, which in turn depends on a specific salt. As far as I know, it's impossible for a user to tell which policy was created from which FS/salt (when displaying them with the standard tools). If this were the case, then the problem could obviously be solved quite easily. I presume the e4rcypt add_key variant with a path does the right thing, but that's not always what a user wants, e.g. when setting up multiple directories or just setting up any directories after login.

So, the problem isn't necessarily our capability to create those policies, but the user's capability to choose the correct policy when setting up some directory.

I don't think so: pam_e4crypt currently uses EXT4_MAX_SALT_SIZE, which is defined, at least on my system, in /usr/include/ext2fs/ext2_fs.h to 256.

Huh. ok. I thought it was 16. Maybe it changed at some point. I'll have to check (e.g. in which version) and then update the documentation accordingly. Thanks for the hint!