I think there is a large part of that story missing. If the accounts daemon drops privileges for reading from the user's home, how can it ever get back to its normal state? How could two users run the same operation concurrently?
Normally that privilege dropping should happen after forking, right? And if it does the parent process should respond to gdm's inquiry.
That being said, the initial settings thing is probably good for a few more escalations as its usecase does not seem to fit the standard security measures very well.
> An unprivileged process may change its real UID, effective UID, and saved set‐user‐ID, each to one of: the current real UID, the current effective UID or the current saved set‐user‐ID.
accountsservice did something like setresuid(uid, uid, -1), which set both real and effective UIDs, but kept saved set‐user‐ID as root, so that it could re-gain root privileges later.
Setting EUID was the correct course of action; but setting real UID let the unprivileged user kill the process.
Normally that privilege dropping should happen after forking, right? And if it does the parent process should respond to gdm's inquiry.
That being said, the initial settings thing is probably good for a few more escalations as its usecase does not seem to fit the standard security measures very well.