netboot newuser and ecryptfs fails to login

The actual problem is that when encrypted home is chosen on the net install (I used the mini iso), the home directory's permissions are set to 500. Thus, the config files needed to login cannot be written. The original reporter's workaround simply replaced their home directory with the already-700 Private directory.

Attaching a debdiff to only set the mountpoint to read-only in cases where the entire home directory is not ecrypted.

Hi Mackenzie, Luis,

Thanks very much for the bug report, analysis, and patch.

The encrypted home directory mount point is set to 500 to keep you from inadvertently writing unencrypted files into the mount. Should your encrypted home (or private) become unmounted for whatever reason, and some random application writes some data into your unencrypted mountpoint, it would be written to disk in plain text, and you probably wouldn't be able to find that file next time you log and your encrypted directory is mounted properly.

I need to look a little deeper, but I think this is a problem in the net-installer code.

Other installations perform the encrypted mount *before* such configuration files are written into the home directory (such as /etc/skel/*). Thus, these files get written to the disk encrypted.

I'm going to CC Colin Watson on this bug, as he can probably point us to the correct code.

:-Dustin

Also, one point of clarification...

After the system is installed, is this home directory expected to be on a local disk, or networked filesystem?

If you're just planning on netbooting the system, and then using a local disk for the home directory, this should be fine.

If instead you're planning on using NFS/Samba/CIFS to remotely mount the home directory, there's a kernel bug regarding stacked filesystems that would keep this from working right now, Bug #277578.

Cheers,
:-Dustin

I'm on a local system. Nothing from /etc/skel/* was written to my ~ before i chmod'd 700 on ~ and KDE did *not* like that it was 500.

Also, what I see happening with the patch is the following (consider user "test3"):
Before test3 logs in:
drwxr-xr-x 5 test3 test3 4096 2009-02-22 03:59 test3
After test3 logs in:
drwx------ 30 test3 test3 12288 2009-02-22 03:59 test3

Before the patch, when a user setup with ecryptfs bootstrapping is logged in (and thus the drive should be unencrypted), the permissions are 500.

The patch does not affect what the permissions are when the user isn't logged in. In the case that the encrypted directory is not mounted, the mountpoint (~) is 755 regardless. The 55 doesn't matter so much since the files all display as empty to any other user, but that 7 could screw up what you're saying about unencrypted files that go invisible post-mounting.

I think what you're describing would require changing the before-mounting permissions to 555 and having the post-mounting permissions be 700. The patch only covers the latter part of that.

Or maybe not. I just tried creating another user, and this time it was 500 before login and 700 after login (without the patch). On the system where this bug hit me I didn't have another user to see what /home looks like when I'm not logged in.

And some more testing...
I think it's a race. I've got two users that could login only after chmod 700 on their ~. I've got one that could login using the default ecryptfs setup script.

Thanks again for the analysis.

You are *absolutely* right--your home directory once mounted *must* be
perm'd at least 700.

The 500 you're seeing *should* be the unmounted home directory.

If there's non-deterministic behavior here, then, yeah, that's a nasty race :-/

We're doing this in PAM, so I'd expect the mount to complete before
Kubuntu mounts.

I'm downloading the Kubuntu daily right now, and I'll test there.

:-Dustin

Another question...

How did you create this other user?

I have tested thoroughly from the command line using:

 $ sudo adduser --encrypt-home testuser

Mackenzie, can you test using that?

:-Dustin

Whole story:

On one laptop, I installed from the mini iso (and chose kubuntu-desktop, the
mini iso is the same for all *buntu) and found I couldn't login to KDE fully
because it couldn't write configs (rebooted and tried to login multiple times,
was driving people #kubuntu-devel nuts trying to figure out if it was KDE's
fault because KDE was throwing errors). I logged into the VT and saw that ~
had 500 permissions (while logged in as the only user on there). I did a
chmod 700 /home/maco ...and all worked well.

On this laptop, I was trying to figure out why that occurred, and here is where
I edited the ecryptfs-setup-private script. The first user I created with
adduser --encrypt-home was test3. When that user is not logged in the
permissions are 755. When that user is logged in, the permissions are 700.

Then after what you said I did some more testing. I commented out the if
statement I had added (so back to the original code) and did adduser --
encrypt-home test5. When this user is not logged in, the permissions are 500.
When this user is logged in the permissions are 700.

On Sun, Feb 22, 2009 at 11:49 PM, Mackenzie Morgan <email address hidden> wrote:
> Then after what you said I did some more testing. I commented out the if
> statement I had added (so back to the original code) and did adduser --
> encrypt-home test5. When this user is not logged in, the permissions are 500.
> When this user is logged in the permissions are 700.

Okay, and when is the case, is "test5" able to log in and use Kubuntu
as expected?

:-Dustin

Hi Mackenzie-

I still haven't been able to reproduce this issue.

I just installed from the mini.iso in a KVM, and tasksel'd Kubuntu onto it.

Encrypted home dir mounts like a champ, and is readable on reboot.

:-Dustin

I guess you are not using a fully automated install. Try using a preseed
file with all the questions you need for a basic installation.

On Wed, Mar 18, 2009 at 6:49 PM, Dustin Kirkland
<email address hidden>wrote:

> Hi Mackenzie-
>
> I still haven't been able to reproduce this issue.
>
> I just installed from the mini.iso in a KVM, and tasksel'd Kubuntu onto
> it.
>
> Encrypted home dir mounts like a champ, and is readable on reboot.
>
> :-Dustin
>
> --
> netboot newuser and ecryptfs fails to login
> https://bugs.launchpad.net/bugs/317895
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
----)(-----
Luis Mondesi
Maestro Debiano

----- START ENCRYPTED BLOCK (Triple-ROT13) ------
Gur Hohagh [Yvahk] qvfgevohgvba oevatf gur fcvevg bs Hohagh gb gur fbsgjner
jbeyq.
----- END ENCRYPTED BLOCK (Triple-ROT13) ------

Can you please attach such a preseed file that you have used to
produce this problem (without passwords, obviously)?

:-Dustin

Hello Dustin,

If you see my original post (the first one) it does mention the preseed file is attached to this bug report.

http://launchpadlibrarian.net/21266763/ubuntu-desktop-experimental.seed

Don't worry, I poked him on IRC about 2 minutes after he asked going "it's
already there *link*" I think he forgot to scroll up when he asked. I also
think he already started playing with it.

I think there's something race-y about this. On the same hardware as before,
I did the same install with the same options....and KDE loaded fine. pfft.
Dustin tried it twice and it worked for him too.

maco-

Any chance you've been able to reproduce this problem on Jaunty GA?

:-Dustin

No, haven't reproduced it in the last two tries I made.

I believe that this issue was fixed in the Jaunty installer.

If you can still reproduce this issue, please, by all means, re-open this bug!

Thanks,
:-Dustin