Re: [PATCH] liveupdate: add LIVEUPDATE_SESSION_GET_NAME ioctl

[Luca Boccassi <luca.boccassi@gmail.com>]

On Tue, 31 Mar 2026 at 20:28, Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
>
> On Tue, Mar 31, 2026 at 3:07 PM Luca Boccassi <luca.boccassi@gmail.com> wrote:
> >
> > On Tue, 31 Mar 2026 at 19:34, Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
> > >
> > > On Tue, Mar 31, 2026 at 1:56 PM <luca.boccassi@gmail.com> wrote:
> > > >
> > > > From: Luca Boccassi <luca.boccassi@gmail.com>
> > > >
> > > > Userspace when requesting a session specifies a name and gets a FD,
> > > > but then there is no way to go back the other way and get the name
> > > > given a LUO session FD. This is problematic especially when there
> > > > is a userspace orchestrator that wants to check what FDs it is
> > > > handling for clients.
> > > >
> > > > Resolving the /proc/self/fd/X is lossy as that has a hard limit
> > > > of characters, so names might be truncated. Also requiring going
> > > > through procfs and doing manual string mangling is not a nice
> > > > pattern.
> > >
> > > Hi Luca,
> > >
> > > Thank you for working on this.
> > >
> > > This needs more explanation. The way I see it, the user orchestrator
> > > can be the only one that has access to /dev/liveupdate (and this is
> > > actually enforced by kernel). It opens it and creates session_fds for
> > > any client out there. So, the orchestrator already has the FDs and
> > > sends them to clients(e.g. via SCM_RIGHTS). It then monitors the PIDs
> > > of the clients, and if they die, it closes the session_fds for them,
> > > as their data does not need to be preserved.
> > >
> > > Could you please explain why the user orchestrator would need to query
> > > the session_fds, since it is the one that creates them in the first
> > > place and has to keep them open in order to preserve them during a
> > > live update?
> >
> > The orchestrator cannot and will not hold on to all this state, that
> > is not possible. It will simply hand out session FDs on-demand via an
> > IPC, enforcing a naming convention for the client, and immediately
> > forget about them. Clients will hold them and use them as they see
> > fit, and then store them in the FD store on shutdown if they want to
> > commit them, and that's where the orchestrator will get them back, and
>
> I see. The idea is to expand the LUO Session API to be compatible with
> the systemd FD store API.
>
> > they need to be verified that they come from the right cgroup, what
> > the client's portion of the name is to be able to hand them back after
> > reboot, and so on.
>
> So, if I understand correctly, the enforcement of who gets a systemd
> stored fd returned to them is based on the cgroup name, right?
> Presumably, after a reboot, each VMM would have to start in a separate
> cgroup (using the same name as in the previous kernel) and request its
> session FDs back from systemd. That is what will be used to verify
> ownership, am I correct?

It could work either way, it depends on what the client wants to do
w.r.t state separation. If the client is fine with having a single
service being in charge of all sessions, that's of course ok, it can
have as many as it wants to.
But this also makes it possible to have strict state separation
enforced when that is instead desired. I intend to make the interface
to request a session privileged by default, but also gated by polkit,
so that it is easy to make it unprivileged and scoped to specific
uid/gid/services/etc if one wants to, with a simple polkit rule, and
in that case we really want to be sure that nobody is playing games
with other cgroups' sessions, as a precaution.

I haven't finished getting this part going, but I'm close - the client
asks for a session and provides a name, and the cgroup path of the
caller is prefixed to it when creating the session. That way they are
all tagged in a way that is immutable and unique, and that clients
cannot mess with. If the client wants multiple sessions they'll all
have the same prefix.