QA (public) » openQA Project (public) » openQA Tests (public) » qe-yam

Copy from the bug:

To create the encrypted home, I just opened YAST, User and Group management, selected the user, Edit, and select to encrypt home, give a size, password is asked, and that's all.
One thing that never happens is that the user's files are moved. They are copied but remain in the home folder.

To create the encrypted home, I just opened YAST, User and Group management, selected the user, Edit, and select to encrypt home, give a size, password is asked, and that's all.
One thing that never happens is that the user's files are moved. They are copied but remain in the home folder.

This morning I added a comment but it is gone, so here again.

I fixed the problem by changing /etc/pa.d/sddm to

auth optional pam_mount.so
auth include common-auth
account include common-account
password include common-password
session required pam_loginuid.so
session include common-session
session optional pam_cryptpass.so
session optional pam_mount.so

The first line and last two lines were added, and since then I was able to log in.

What still is an issue is that the encrypted home is not properly dismounted after log out, which could result in corrupted files, as I discovered in earlier opensuse versions.

bump

so the bug is still open and looks like will never be fixed. @dheidler, what do you propose?

If the bug won't get fixed, we can't do anything but drop the feature.

dheidler wrote:

If the bug won't get fixed, we can't do anything but drop the feature.

As the bug still talks about gdm only why didn't you put the information it fails on gdm too there?
Also maybe it could be reassigned to pam people...

I mean the bug now describes the issue only on sddm.

Spoke to Rodion, they don't have said scenarios, so we could simply create them, but he's also proposing to automate them with autoyast (which is a great idea)

A quick idea:

• gnome + separate home encrypted on btrfs with snapshots
• minimal x + lvm with encrypted separate home + xfs

Having HDD with these on the functional job group we could spin up other tests that touch the x11 applications mostly, and maybe things like evolution (although SLED might have more interest?)

After discussion with Yifan, we will wait for the feedback to know if such scenario is supported and if so what are expectations and then act on this accordingly.

Hi folks,

Checked with release and product side, and talked to people who had experiences with this. The encrypted home is indeed a supported use case for SLED, though the techniques of implementing it evolves.

Thank you for bringing it up, it is worthy of doing, and I think the implementation timeline is best scheduled by the agile team :-) Hope the information helps.

@Rodion, would you like to move forward with the autoyast approach? This sparked the idea to have an autoyast workshop for the QSFU team, and would then... be a perfect candidate, wdyt?

See for the reason of tracker change: http://mailman.suse.de/mailman/private/qa-sle/2020-October/002722.html