getpwuid is failing on classic image

[Sergey Borovkov]

Both getpwuid() and getpwuid_r() are failing on classic image on RPI.
Jul 25 12:01:44 ubuntu ubuntu-core-launcher[3251]: (ld-linux-armhf.so.3:3251): GLib-WARNING **: getpwuid_r(): failed due to unknown user id (0)
Jul 25 12:01:44 ubuntu ubuntu-core-launcher[3251]: (ld-linux-armhf.so.3:3251): GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' failed

This is what I am getting from gstreamer initialization. Similar stuff happens with python code which tries to use getpwuid and failing to do that.
Tried both stable version and snap-confine 1.0.38 from proposed.

[Jamie Strandboge (jdstrand)]

Thank you for reporting a bug.

Do you see any security policy denials in the log? Eg, please attach the output of 'grep audit /var/log/syslog'.

[Sergey Borovkov (serge-borovkov)]

Hi Jamie. I think I might have put a wrong tag on the bug since I am running in devmode. And there are no related denials as well.
Just additional detail about bug though - I built snappy only image with latest kernel and gadget and installed the same snap there. This issue is not present there. It's also not present on classic outside of snaps.

[Jamie Strandboge (jdstrand)]

Thanks Sergey. I removed the tag and put this back to new. I wonder if this has anything to do with how snap-confine is handling bind mounts (eg bug #1606277). While that bug is about log-observe, I mentioned in it that nss (/var/lib/extrausers) would like be broken. That said, you mentioned that the ubuntu-core-launcher in updates is also affected, so maybe this was never handled properly.

[Zygmunt Krynicki (zyga)]

I think this problem boils down to core incompatibility between UIDs and GIDs on the core snap (and all the other snaps) and the classic (host) filesystem. Without an active remapping layer I don't see a way to solve the issue.

I'm not aware of any kernel features that would allow us to do this but perhaps I am mistaken. Perhaps some combination of ID namespaces and something else would be sufficient to address this.

One way to look at this is NFS share problem, the idmap is a core feature that allows various hosts to access files in a consistent way. Whatever makes NFS work might be used to make core snap work.

[Oliver Grawert (ogra)]

you could probably hook that into the uid cache that squashfs uses ...

http://lxr.free-electrons.com/source/Documentation/filesystems/squashfs.txt#L188

[Gustavo Niemeyer (niemeyer)]

Apparently the message indicates this is about uid 0, which would hint at it being unrelated to user id mapping.

On a quick search, this issue covers the same problem:

https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/649917

with the relevant comment from Evan Broder:

    Apparently an /etc/passwd file isn't sufficient - you actually need a nsswitch.conf file and libnss_files for getpwid_r to return something useful.

    Updated patch attached. I've tested it locally and confirmed that it suppresses the GLib warning, and the new version has been pushed to my PPA for test building

and one of the fixes

https://launchpadlibrarian.net/58336075/plymouth_0.8.2-2ubuntu6.debdiff

[Oliver Grawert (ogra)]

we should have a fresh bug for the UID mapping vs FS ownerships though, this is a serious problem, yet probably not related to this specific bug

[Gustavo Niemeyer (niemeyer)]

It is only a serious problem if we find a serious bug about it. Meanwhile it's an inconvenience which we should try to fix when the cost-benefit pays off.

[Sergey Borovkov (serge-borovkov)]

Just a note - everything works for me if I change line in /etc/nsswitch.conf from
passwd: compact to
passwd: files