[derefr]

Process owned by human-user fork(2)s and then exec(2)s suid program owned by program-user; program owned by program-user then does most of the work; but calls back over a domain socket to program owned by human-user to get it to do things on the program-user’s behalf.

Picture: local DB client, remote DB server. Server can stream a file to the client for the client to write to disk. “On the same machine, as a different user” is just the trivial case of “over the network.”

[jcrawfordor]

This doesn't actually provide the benefit of application isolation though; if the software is malicious or vulnerable the as-user component could be as well. Remember that the biggest use case for application isolation is untrusted applications. Essentially any setuid-based approach to isolation requires a trusted developer using very good practices to remain secure, and that's why it's faded away.

[derefr]

What's insecure about setuid if the setuid user isn't a privileged user? For example, a setuid-nobody program, shouldn't be any more insecure than a systemd service spawned as User=nobody, no?

(Also, implied is that any untrusted logic lives in the spawned program, while the "client" program is simple and auditable. As I said: like a database client vs a database server. Or how about: like a client that wants to print something, vs. a print server embedding untrusted printer drivers!)

[dathinab]

like I sayed: hacks