scoped_cred's Drop resets the worker thread's effective uid/gid to a hardcoded 0, assuming the server runs as root. That breaks an unprivileged server granted CAP_SETUID/CAP_SETGID (e.g. via systemd's AmbientCapabilities=): set_creds sees the capability and switches, but restoring to 0 poisons the thread. A first switched request's Drop parks the thread at euid 0; the next switch to a non-zero uid clears the thread's effective capabilities (capabilities(7), "Effect of user ID changes on capabilities"); that request's Drop then fails EPERM, and the thread is stuck with the guest uid's credentials. Every later request it handles -- including ones for guest root -- fails EACCES/EPERM on host files that uid cannot reach. Any guest issuing requests as more than one uid wedges within a few ops. A Debian guest running 'apt-get update' (whose fetch methods drop to the _apt user) reproduces it: the InRelease/Packages renames fail with 'rename failed, Permission denied'. Capture the effective id before switching and restore that on drop. A root-run server captures 0 and is unchanged; an unprivileged server now only switches between non-zero uids, never clearing its caps -- and the worker thread no longer escalates itself to host euid 0. Signed-off-by: Hans Jørgen Hoel <hansjorg@urkilden.no> Assisted-by: Claude Code: claude-fable-5 (cherry picked from commit 4c9c185c8ac02b1bb21420834b5651767f0c9cc9) Signed-off-by: Sergio Lopez <slp@redhat.com>