Allright, my quest for running on encrypted /home/ continues. Now I have managed to get sillykbd in such a shape that it is useful in password prompting in pre-init phase.

I do however have some problems I would like to share with you in case somebody can advice me.

This is how I have proceeded;

• First I need of course to boot into plain console without any GUI running. At this point "/dev/mmcblk0p3" and "/dev/mmcblk0p1" are not mounted yet.
• Then, I create a a directory entry "/enc_home" for the encrypted files to go into. I will now also change "/etc/fstab" so that "/dev/mmcblk0p3" will be mounted to "/enc_home" instead of "/home":

• Next thing I do is I mount the "/enc_home" and copy everything off to "/root/home_backup". After that I do "rm -rf /enc_home/*".
• Then I will mount "/home" as encfs on "/enc_home":

• Now, to finish this off I copy back all the stuff to the new cryptodir: "cp -a /root/home_backup/* /home/"

After this I have whole "/dev/mmcblk0p3" encrypted, and I need to setup my "/sbin/preinit" so that it does the right things to ask for the key and set up decryption on next boot.

So far so good.

Now, on next boot I get the password prompt and enter the correct key.
However, system does not come up but reboots after a while. Once I got so far as to enter PIN-code of my SIM, but after that it rebooted again.

Well, my first thought was that maybe wholesale encfs running would take so much time on boot that watchdog bit me on the tail but closer inspection shows that this is not the case.

When I restored my usual setup and checked the logs, I found that there was loads of mounting errors like this:
"devicelockd: aegis_common.cpp(387): ERROR creation of '/home' failed (Transport endpoint is not connected)"
and further on like this:
"GLIB WARNING ** default - Cannot create directory: /home/user/.accounts"

So apparently at some point in initialization some of the aegisfs thingies that get mounted under "/home/user" fail.

Here is the whole bootlog for your reference: http://www.swagman.org/juice/bootlog_encfs

Now, why does this happen?
I have booted my system before so that I have manually mounted normal unencrypted "/dev/mmcblk0p3" into "/home" so I know the reason is not that aegis wants to mount it by itself. It can well run with "/home" already mounted.
Why does it now complain as I similarily present it with a nice decrypted view of the home hierarchy?

Is there some problem mounting the aegis directories overlayed on the encfs? I would assume there should be no objections to that...?

I have been checking bootlogs from a normal boot and a boot where I tried to mount /home as encrypted volume.

The first thing indeed where it goes bonkers is the aforementioned log "devicelockd: aegis_common.cpp(387): ERROR creation of '/home' failed (Transport endpoint is not connected)"

Here you can see filtered logs from normal boot (http://www.swagman.org/juice/n9_syslog_okok_post_ff) and failing boot (http://www.swagman.org/juice/n9_syslog_brkn_post_ff)

You can compare the logs wit meld or similar tool to see how they differ....

Your opinions are appreciated

I will more than likely be of no help, but:
the only time I have seen the error "Transport endpoint is not connected"
is when I've had a disconnect from fuse whilst mounting a remote directory using SSHFS.

Not sure what is means, if any thing, in your case.

Hmmm that kind of makes sense.

I think (and this is just a wild guess, could be I am totally wrong here) that these "aegisfs" mounts are done via FUSE on top of the base file system.

If the mount fails because the base file system under is already a FUSE mounted fs, like encryptfs here that would suggest that FUSE systems cannot be stacked on top of each other.

I really am not sure if this is the case? I kind of assumed it is possible but if tis turns out not to be feasible I will have to rethink my architecture.

Okay, now it is proved. At least some FUSE systems can be stacked on top of each other.

I made a quick test where I created an encfs mount, and then mounted another encfs mount with different set of keys on top of it.
The files that I stored on the topmost file system were encrypted twice, once on the top fs and then again second time on the bottom fs.

So I think this must be some kind of access rights problem, technically it should be possible to mount aegisfs entries on top of an encrypted file system.

Nice find. I hope you can develop something out of this; I would love to be able to create encrypted partitions.

Well, what can be done currently, for example is to encrypt fully your mmcblk0p1 partition, meaning MyDocs directory.
That goes quite far as a security measure as lots of the important and personal stuff are stored there. However, my target was encrypting whole /home partition as that would render the whole device unusable to other parties.

The nice thing about encrypting MyDocs is that it is really easy to use it transparently also when mounting to computer via USB. Encfs volumes can be accessed in any linux computer just by knowing the password as the encryption metadata is stored in the root of the directory.
(I assume it is also possible with windows an mac as encfs is open source, however I do not have much knowledge about either of those)

I propably should post a video to youtube on how the encryption works

I have been trying to find out why sometimes encfs-mounted filesystems fail with error "Transport endpoint is not connected".
This happens when there is lots of concurrent access to the filesystem, and especially when init mounts aegisfs systems on top of my encfs home directory.

First I thought it is a bug in encfs or incompatibility in stacking the aegisfs mount over encfs mount, but it well may be that this is a bug in FUSE itself.
Some googling proves that this bug exists at least in fuse versions 2.8.x. and it should be corrected in the latest stable release (2.9.1)

Now, I would like to try this out with a newer fuse versions but the problem is that fuse is not built as a module in the harmattan kernel I am using (2.6.32.54-dfl61-20121301)

Building kernel modules for the kernel is no brainer, I have been doing that in scratchbox for quite a long time now.
Building the whole kernel is something I have not tried yet. I would appreciate pointers and tips regarding that.

Update... It seems that I may not need to build the kernel to fix this.

With help from Hurrian and this posting by javispedro http://talk.maemo.org/showthread.php...81#post1178281
I managed to remove the problematic aegisfs mounts from my device.

However, this seems to be like trying to rip bubblegum out from your hair, as I tried remounting the encrypted home, again a new problem came up. The dreaded "(Transport endpoint is not connected)" hit me again and device stays in reboot loop.

It looks like that some remains of aegis still try to access /home/user, even as the mounts have been removed.

This time it is "devicelockd" that wants to mess up the system:


Oct 16 09:41:26 (2012) devicelockd: aegis_common.cpp(387): ERROR creation of '/home/user' failed (Transport endpoint is not connected)
Oct 16 09:41:26 (2012) devicelockd: aegis_storage.cpp(314): ERROR cannot create directory '/home/user/.aegis/ps/Pe/'
Oct 16 09:41:26 (2012) devicelockd: aegis_storage.cpp(809): ERROR init_storage: cannot bind storage '/home/user/.aegis/ps/Pe/' to file
Oct 16 09:41:26 (2012) devicelockd: aegis_storage.cpp(1250): ERROR get_files: access denied
Oct 16 09:41:26 (2012) devicelockd: aegis_crypto.cpp(1996): ERROR aegis_crypto_decrypt: bb5_fprot_decrypt('AID::com.nokia.maemo.devicelock .') returned -4
Oct 16 09:41:26 (2012) devicelockd: aegis_crypto.cpp(1997): ERROR aegis_crypto_decrypt: BB5 ERROR(-1) lib=-1 rom=0 pa=37
Oct 16 09:41:26 (2012) devicelockd: aegis_crypto.cpp(1996): ERROR aegis_crypto_decrypt: bb5_fprot_decrypt('AID::com.nokia.maemo.devicelock .') returned -4
Oct 16 09:41:26 (2012) devicelockd: aegis_crypto.cpp(1997): ERROR aegis_crypto_decrypt: BB5 ERROR(-1) lib=-1 rom=0 pa=37
Oct 16 09:41:26 (2012) devicelockd: aegis_crypto.cpp(1996): ERROR aegis_crypto_decrypt: bb5_fprot_decrypt('AID::com.nokia.maemo.devicelock .') returned -4
Oct 16 09:41:26 (2012) devicelockd: aegis_crypto.cpp(1997): ERROR aegis_crypto_decrypt: BB5 ERROR(-1) lib=-1 rom=0 pa=37


What is the function of devicelockd?
Can it be safely disabled, from the daemon name I guess it is related to the device locking and that does not work in open mode anyway... From the error messages it looks like the access point it needs to work on is defined statically inside some library and hence cannot easily be modified to point somewhere else.

Here is again syslog of the relevant boot attempt:
http://www.swagman.org/juice/n9_syslog_16.10.2012