Comment 51 for bug 1620771

Zygmunt, the code I was specifically referring to in comment #49 is migrateXauthority() in https://github.com/snapcore/snapd/blob/master/cmd/snap/cmd_run.go (see bug #1902250). If I understood correctly, this merely reads and copies (on behalf of the calling user) the content of a credential file before the app is invoked, so this particular function shouldn't be constrained by "the semantics of symbolic links for apparmor" or "mount namespace configuration" considerations, right? But it still checks for symlinks in the path to the Xauthority file. Why? (preferably answer under bug #1902250)

I still think it was a fair comment that this particular function should simply have switched the EUID/EGID of the process temporarily to that of the calling user for the duration of the operation of reading the Xauthority file, and then let the kernel do the DACL checks, rather than trying to do access-control checks manually and worry about symlink trickery from user space.

From that one data point, forgive me for wondering aloud whether all other places in snapd where symbolic links are also rejected (which I haven't read yet!) really all do so for much better reasons than migrateXauthority() ...

If you have a detailed write up or presentation of all the architectural considerations that went into the design of snapd, especially the parts that conflict with symlinks and NFS mounting, I'd love to read that and would much appreciate a pointer.