On Mon, Aug 10, 2026 at 11:06:27AM +0300, Kostiantyn Kostiuk wrote: > Hi Valentino, > > Sorry for the long delay. > I have a question for you > > On Tue, Jul 14, 2026 at 7:10 PM Valentino Paulon < > [email protected]> wrote: > > > > > So, you propose to call seteuid/setegid before any I/O operation? > > > > > > Yes, specifically for the SSH commands, because they're unusual in > > > that we're doing stuff on behalf of an unprivileged user. > > > > +1 on the euid/egid direction -- as the reporter that's the outcome I > > was hoping for. It confines every step (read, mkdir, create, rename, > > chown) to what the target user could already do himself, which removes > > the whole TOCTOU class instead of chasing one instance of it. > > > > A few implementation details that tend to bite with this pattern, in > > case they save a round-trip: > > > > - drop the supplementary groups too, not just egid: initgroups() (or > > setgroups() with the user's list) while still root, otherwise the > > agent's effective access won't match the user's in either direction > > > > Technically, there is no limitation to running QGA in unprivileged mode. > Normally, it is a system daemon, but this is not mandatory. > In this case, we can not call initgroups because the caller must > have CAP_SETGID. > We can call initgroups only when QGA runs as root. What do you think?
In any practical sense it is a system daemon given the set of commands it is exposing. Thus, IMHO, deploying as an unprivileged user should be considered a broken deployment. We could make that explicit by refusing to launch. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
