Comment 49 for bug 1620771

I have so far looked at the reasons for why snapd is so hostile to symbolic links only in one particular context, but what I found in the golang source code left me rather worried, and with the impression that the author of that code has a rather pre-POSIX, 1980s understanding of Unix file-access-control security. The problems with symbolic links may be just one of many problem and potential security vulnerabilities caused by snapd not changing its "effective" UID/GID to that of the user when it accesses resources on behalf of the user!

I've so far only looked at the relevant code for when snapd makes a copy of the user's $XAUTHORITY file, in order to provide a snap app access to the X11 access cookie, which fails for no good reason if there is a symlink in the paths. The details are in my comments in bug #1902250, but in a nutshell: the developers had probably heard of historic time-of-check-to-time-of-use attacks on privileged processes (here: snapd) being tricked into accessing the wrong file via flipping symbolic links, and rather than implementing the real solution (namely switching the EUID to that of the user before accessing the resource, such that the kernel performs all applicable security checks properly) they try do a long list of known-to-not-work 1980s workarounds, from the time before POSIX introduced effective/real/saved UIDs/GIDs, involving manually checking file permissions and whether there are any symlinks in the path. This looks very much like a developer training issue, I'm afraid, i.e. not having understood the purpose of the seteuid()/setguid() system calls, perhaps combined with golang not documenting its corresponding wrapper functions very well. The relevant XAUTHORITY access code could be rewritten much simpler and more secure that way, eliminating not just the symlink problem. I now suspect the same may also apply for other parts of snapd.

I do strongly encourage in-depth code security reviews of snapd. There may be lots of low-hanging fruits there!