Comment 2 for bug 1913470

Thanks for the bug report.

Initially I wasn't able to reproduce it with a pristine installation of Ubuntu Bionic + sssd, then aa-enforcing sssd, and then enabling overlayroot=tmpfs. sssd was able to start successfully.

Then, we had a chat on IRC where Andreas let me know that sssd's autopkgtest does have scripts that setup a simple LDAP + sssd auth scheme, so I used that to perform the tests. I download sssd's source, manually ran the debian/tests/ldap-user-group-ldap-auth, which create a "testuser1" in the LDAP database. I also tested that this user is able to login and ssh into the VM. Then, aa-enforced sssd and enabled overlayroot=tmpfs:

# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=491068k,nr_inodes=122767,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=100488k,mode=755)
/dev/sda2 on /media/root-ro type ext4 (ro,relatime,data=ordered)
tmpfs-root on /media/root-rw type tmpfs (rw,relatime)
overlayroot on / type overlay (rw,relatime,lowerdir=/media/root-ro,upperdir=/media/root-rw/overlay,workdir=/media/root-rw/overlay-workdir/_)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
...

To no avail: I'm still able to start sssd and perform logins/ssh into the machine.

I'll continue investigating tomorrow, but it's important to obtain a reproducer for this one because we will need to SRU it into Bionic.