ext4 encryption trap
Hi!
You encrypt a directory -- sounds easy, right? Support is in 4.4 kernel, my machines run newer kernels than that. Encrypting root would be hard, but encrypting parts of data partition should be easy.
Ok, lets follow howto... Need to do tune2fs. Right. Aha, still does not work, looks like I'll need to reboot.
Hmm. Will not boot. Grub no longer recognizes my /data partition, and that's where new kernels are. Old kernels are in /boot, but those are now useless. Lets copy new kernel on machine using USB stick. Does not boot. Fun.
tune2fs on root filesystem is useless, as it is too old. New one is ... on the data partition. Right. Ok, lets bring newer version of tune2fs in. "encryption" feature can not be cleared.
Argh! Come on, I did not even create single encrypted directory on the partition. I want the damn bit to go off, so I can go back to working configuration. "Old kernels can not read encrypted files" sounds ok, but "old kernels can not mount filesystem at all" is not acceptable here :-(.
Is there way to go back? Restoring 400GB from backups would not be fun :-(.
On a related note, would it be possible to return some kind of error when encrypted directory is accessed without available keys? I use unison for backups/sync, and if I ever make a mistake of trying to sync in non-decrypted state, results would be very very bad...
Thanks,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 18 lines · CEST Pavel Machek
Hi!
You encrypt a directory -- sounds easy, right? Support is in 4.4 kernel, my machines run newer kernels than that. Encrypting root would be hard, but encrypting parts of data partition should be easy.
Ok, lets follow howto... Need to do tune2fs. Right. Aha, still does not work, looks like I'll need to reboot.
Hmm. Will not boot. Grub no longer recognizes my /data partition, and that's where new kernels are. Old kernels are in /boot, but those are now useless. Lets copy new kernel on machine using USB stick. Does not boot. Fun.
tune2fs on root filesystem is useless, as it is too old. New one is ... on the data partition. Right. Ok, lets bring newer version of tune2fs in. "encryption" feature can not be cleared.
Quoted 7 lines
Argh! Come on, I did not even create single encrypted directory on the partition. I want the damn bit to go off, so I can go back to working configuration. "Old kernels can not read encrypted files" sounds ok, but "old kernels can not mount filesystem at all" is not acceptable here :-(.
Is there way to go back? Restoring 400GB from backups would not be fun
I have not tried it myself, but this should work?
debugfs -w -R "feature -encrypt" /dev/device
(assuming the feature flag is called "encrypt")
Cheers,
Bernd
Quoted 25 lines · Bernd Schubert
Quoted 24 lines · CEST Pavel Machek
Hi!
You encrypt a directory -- sounds easy, right? Support is in 4.4 kernel, my machines run newer kernels than that. Encrypting root would be hard, but encrypting parts of data partition should be easy.
Ok, lets follow howto... Need to do tune2fs. Right. Aha, still does not work, looks like I'll need to reboot.
Hmm. Will not boot. Grub no longer recognizes my /data partition, and that's where new kernels are. Old kernels are in /boot, but those are now useless. Lets copy new kernel on machine using USB stick. Does not boot. Fun.
tune2fs on root filesystem is useless, as it is too old. New one is ... on the data partition. Right. Ok, lets bring newer version of tune2fs in. "encryption" feature can not be cleared.
Argh! Come on, I did not even create single encrypted directory on the partition. I want the damn bit to go off, so I can go back to working configuration. "Old kernels can not read encrypted files" sounds ok, but "old kernels can not mount filesystem at all" is not acceptable here :-(.
Quoted 8 lines
Quoted 1 line
Is there way to go back? Restoring 400GB from backups would not be fun
I have not tried it myself, but this should work?
debugfs -w -R "feature -encrypt"
/dev/device(assuming the feature flag is called "encrypt")
Yes, I figured out debugfs could be used to do this. (But thanks for the command line). If all tunefs did was to set the bit, this is safe. Is it?
[I guess I can do fsck -fn, debugfs, fsck -fn; if it passes I should be safe, if it does not I can turn +encrypt back on, and would be no worse than I'm now. Hmm?]
Thanks,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 35 lines · Pavel Machek
Quoted 25 lines · Bernd Schubert
Quoted 24 lines · CEST Pavel Machek
Hi!
You encrypt a directory -- sounds easy, right? Support is in 4.4 kernel, my machines run newer kernels than that. Encrypting root would be hard, but encrypting parts of data partition should be easy.
Ok, lets follow howto... Need to do tune2fs. Right. Aha, still does not work, looks like I'll need to reboot.
Hmm. Will not boot. Grub no longer recognizes my /data partition, and that's where new kernels are. Old kernels are in /boot, but those are now useless. Lets copy new kernel on machine using USB stick. Does not boot. Fun.
tune2fs on root filesystem is useless, as it is too old. New one is ... on the data partition. Right. Ok, lets bring newer version of tune2fs in. "encryption" feature can not be cleared.
Argh! Come on, I did not even create single encrypted directory on the partition. I want the damn bit to go off, so I can go back to working configuration. "Old kernels can not read encrypted files" sounds ok, but "old kernels can not mount filesystem at all" is not acceptable here :-(.
Quoted 8 lines
Quoted 1 line
Is there way to go back? Restoring 400GB from backups would not be fun
I have not tried it myself, but this should work?
debugfs -w -R "feature -encrypt"
/dev/device(assuming the feature flag is called "encrypt")
Quoted 7 lines
Yes, I figured out debugfs could be used to do this. (But thanks for the command line). If all tunefs did was to set the bit, this is safe. Is it?
[I guess I can do fsck -fn, debugfs, fsck -fn; if it passes I should be safe, if it does not I can turn +encrypt back on, and would be no worse than I'm now. Hmm?]
Ok, done, fsck passed, I'm back to previous configuration.
I guess I was too optimistic. Using ext4 encryption would require at least new e2fsprogs at the root filesystem, which was something I was hoping to avoid.
Best regards,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 44 lines · Pavel Machek
Quoted 35 lines · Pavel Machek
Quoted 25 lines · Bernd Schubert
Quoted 24 lines · CEST Pavel Machek
Hi!
You encrypt a directory -- sounds easy, right? Support is in 4.4 kernel, my machines run newer kernels than that. Encrypting root would be hard, but encrypting parts of data partition should be easy.
Ok, lets follow howto... Need to do tune2fs. Right. Aha, still does not work, looks like I'll need to reboot.
Hmm. Will not boot. Grub no longer recognizes my /data partition, and that's where new kernels are. Old kernels are in /boot, but those are now useless. Lets copy new kernel on machine using USB stick. Does not boot. Fun.
tune2fs on root filesystem is useless, as it is too old. New one is ... on the data partition. Right. Ok, lets bring newer version of tune2fs in. "encryption" feature can not be cleared.
Argh! Come on, I did not even create single encrypted directory on the partition. I want the damn bit to go off, so I can go back to working configuration. "Old kernels can not read encrypted files" sounds ok, but "old kernels can not mount filesystem at all" is not acceptable here :-(.
Quoted 8 lines
Quoted 1 line
Is there way to go back? Restoring 400GB from backups would not be fun
I have not tried it myself, but this should work?
debugfs -w -R "feature -encrypt"
/dev/device(assuming the feature flag is called "encrypt")
Quoted 7 lines
Yes, I figured out debugfs could be used to do this. (But thanks for the command line). If all tunefs did was to set the bit, this is safe. Is it?
[I guess I can do fsck -fn, debugfs, fsck -fn; if it passes I should be safe, if it does not I can turn +encrypt back on, and would be no worse than I'm now. Hmm?]
Quoted 5 lines
Ok, done, fsck passed, I'm back to previous configuration.
I guess I was too optimistic. Using ext4 encryption would require at least new e2fsprogs at the root filesystem, which was something I was hoping to avoid.
I'm trying to make some experiments on USB stick...
Hmm. I guess error handling in add_key should be improved?
pavel@duo:/mnt$ ~/g/e2fsprogs/misc/e4crypt add_key -S salt.txt Invalid salt: salt.txt pavel@duo:/mnt$ ~/g/e2fsprogs/misc/e4crypt add_key -S /media/pavel/8EE9-E39F/salt.txt EXT4_IOC_GET_ENCRYPTION_PWSALT: Inappropriate ioctl for device pavel@duo:/mnt$
(The first one is probably ok, but why it accepts path instead of hex value?)
Best regards,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html