Encrypted home directory file Input/output error

[Duncan]

This is a fresh install of karmic koala alpha-5 (Ubuntu karmic (development branch)) on a new machine using the alternate install CCD (required LVM+software RAID).
The "encrypt home directory" option was selected during the install.

Once complete I was unable to log in via GDM. This reported problems accessing the $HOME/.ICEauthority file.
Logging in via the console was possible. Attempts to read or modify (chown||chmod) the .ICEauthority file as the user or root (again from console) failed with "Input/output error". Ultimately this was resolved by deleting then recreating (touch .ICEauthority) the file as root.

I have now encountered the same problem accessing files in the $HOME/.gnupg directory while trying to import keys.
A simple script which does an fopen()/fclose() on all files under $HOME when run as either the user or root returns:

Unable to open /home/djf/.compiz-gnomecompat
Unable to open /home/djf/.pulse-cookie
Unable to open /home/djf/gnupg/secring.gpg
Unable to open /home/djf/gnupg/gpg.conf
Unable to open /home/djf/gnupg/trustdb.gpg
Unable to open /home/djf/gnupg/pubring.gpg
Unable to open /home/djf/.config/compiz/compizconfig/config
Unable to open /home/djf/.config/user-dirs.locale
Unable to open /home/djf/.dbus/session-bus/5cf1f2eb5de5eb7933fc8c964aa0e4c9-0
Unable to open /home/djf/.cache/compizconfig/cubeaddon.pb
Unable to open /home/djf/.cache/notify-osd.log
Unable to open /home/djf/.cache/event-sound-cache.tdb.5cf1f2eb5de5eb7933fc8c964aa0e4c9.x86_64-pc-linux-gnu
Unable to open /home/djf/.pulse/5cf1f2eb5de5eb7933fc8c964aa0e4c9-device-volumes.tdb
Unable to open /home/djf/.pulse/5cf1f2eb5de5eb7933fc8c964aa0e4c9-card-database.tdb
Unable to open /home/djf/.pulse/5cf1f2eb5de5eb7933fc8c964aa0e4c9-stream-volumes.tdb

All of these files are owned by the user in question:
djf@unicorn:~/bug$ ls -l /home/djf/.pulse-cookie
-rw------- 1 djf djf 12288 2009-09-07 10:42 /home/djf/.pulse-cookie

The files in gnupg were copied (cp $src $dest) from .gnupg
Between discovering problem .gnupg files and running the script they started to behave - possibly due to running software-properties-gkt being run in that interval (?).

As an example of the access error:
djf@unicorn:~$ cat /home/djf/.config/compiz/compizconfig/config
cat: /home/djf/.config/compiz/compizconfig/config: Input/output error

dmesg gains another of these messages for each failed access:
[87804.727437] Valid eCryptfs headers not found in file header region or xattr region
[87804.727441] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO

This may also explain why pulseaudio appears to be suffering (device manager says "connection refused",
hence no sources or sinks).

The machine has 2 1TB HDD configured as 3 x software raid 1:
/dev/md0 == /boot (29.80 GB) ext2
/dev/md1 == encrypted swap (29.80 GB)
/dev/md2 == LVM volume group vg00
    /dev/mapper/vg00-root00 == / (29.80 GB) ext4
    /dev/mapper/vg00-home00 == /home (29.80 GB) ext4, user directories encrypted.
    /dev/mapper/vg00-snap00 == /snap (29.80 GB) ext4
    /dev/mapper/vg00-data00 == /data (782.51 GB) ext4

The encrypted home directory uses the default install, mount reports:
/home/djf/.Private on /home/djf type ecryptfs (ecryptfs_sig=XXXXXX,ecryptfs_fnek_sig=XXXXXX,ecryptfs_cipher=aes,ecryptfs_key_bytes=16)

[Duncan (dfyfe)]

Should have added this is all 64 bit.

[Dustin Kirkland  (kirkland)]

Hi Duncan-

Thanks for the detailed bug report. Something strange is going on here.

I have an idea of what might have happened. Hopefully you can confirm.

With an encrypted home setup, your home directory has two different "states"...mounted and unmounted.

When your $HOME is unmounted, it will have permissions 500, such that you can't inadvertently write unencrypted data to $HOME. However, this doesn't prevent root from writing data there.

Once your $HOME is mounted, you'll see that entry in your mount table. And the permissions on $HOME will change to 700, such that your user can read/write into that mountpoint.

From the errors you're seeing, it looks to me like you copied the files the kernel is complaining about into the mountpoint when your home directory was *not* mounted, probably as root. Can you confirm or deny this?

To establish the encrypted mount point, you need to first login as your user, and then copy your existing data (like .gnupg) into $HOME.

:-Dustin

[Dustin Kirkland  (kirkland)]

Actually, let me make some more specific questions...

1) Make sure $HOME is not mounted.
  $ ecryptfs-umount-private
  $ mount | grep $USER
When you're sure $HOME is not mounted
  $ cd $HOME
  $ ls -alF $HOME

2) Mount $HOME
  $ ecryptfs-mount-private
  $ mount | grep $USER
  $ cd $HOME
  $ ls -alF $HOME

3) Also, examine your encrypted directory.
  $ ls -alF /home/.ecryptfs/$USER/.Private

:-Dustin

[Duncan (dfyfe)]

Thanks for the response Dustin.

In answer to your first question:

All of the problem files were created either during install or during
initialization at first or subsequent login. None of them were created
manually (the .gnupg were the 'defaults', I discovered they were a
problem when I tried to add the first PPA repository key ala
"gpg --keyserver keyserver.ubuntu.com --recv NNNNNNNN" ).

I don't know when they were created in relation to the problem
.ICEauthority file but I assume it was at the same time and they have
been present (and problematic) ever since.

I can also confirm that the remaining problem files can be deleted by
the user. Once recreated they behave normally (as .ICEauthority did).

All data copied into the mounted, ecryptfs filesystem since
.ICEauthority was fixed have been fine.

As noted below, files created in the bare /home/$USER are hidden by
mounting of the ecryptfs filesystem over it -- as expected from
standard mount behaviour.

Similarly, a process with a $PWD of the bare /home/$USER when
the ecryptfs filesystem is mounted continues to see the bare directory
when accessed relative to that directory but the ecryptfs when using
an externally qualified full path. Such a process can create files in both
locations but neither is visible within the other directory
ie. cd /
    ecryptfs-umount-private
    cd /home/$USER
    ecryptfs-mount-private
    touch snafu
    touch $HOME/snafu2
    ls (lists unencrpyted directory, sees snafu but not snafu2)
    ls $HOME (lists the ecryptfs contents, sees snafu2 but not snafu)

In answer to your "specific questions", please find a
a list of actions and results in the following attachment.

Hope that helps.

Have fun,
Duncan

[Dustin Kirkland  (kirkland)]

Thanks for the info.

I just did a fresh install from the karmic-alternate-amd64 iso, and I
couldn't reproduce any of these issues.

The install went without a hitch.

Rebooted, logged into the new system. Verified my data was encrypted
on disk, mounted and decrypted just fine, automatically. dmesg is
clean of any ecryptfs errors.

I'm not sure where that leaves us...

:-Dustin

[Duncan (dfyfe)]

Hi Dustin,
I have now tried and failed to recreate the problem with new user accounts (created at console and via user-admin).
As indicated previously, because these have all been "default" content files I have been able to solve the problem by deleting them and recreating them.

I think you are right that without further instances, or the ability to "recreate at will", this problem will be difficult to understand let alone resolve. With this one report (this one) and an easy solution (delete the offending files from a console) I'd be inclined to let it lie.

Have fun,
Duncan

[Dustin Kirkland  (kirkland)]

Thanks, Duncan.

I'm going to leave the report "open", but in "incomplete" state, as I
don't doubt you experienced the problem, its just that we haven't been
able to trigger the scenario to reproduce it.

Cheers,
:-Dustin