Re: [libvirt PATCHv1 8/8] docs: virtiofs: add section about ID remapping

On a Monday in 2023, Daniel P. Berrangé wrote: > On Mon, Sep 11, 2023 at 03:51:28PM +0200, Ján Tomko wrote: > > Signed-off-by: Ján Tomko <jtomko(a)redhat.com&gt; > > --- > > docs/kbase/virtiofs.rst | 29 +++++++++++++++++++++++++++++ > > 1 file changed, 29 insertions(+) > > > > diff --git a/docs/kbase/virtiofs.rst b/docs/kbase/virtiofs.rst > > index 5940092db5..ecfb8e4236 100644 > > --- a/docs/kbase/virtiofs.rst > > +++ b/docs/kbase/virtiofs.rst > > @@ -59,6 +59,35 @@ Sharing a host directory with a guest > > > > Note: this requires virtiofs support in the guest kernel (Linux v5.4 or later) > > > > +ID mapping > > +========== > > + > > +In unprivileged mode (``qemu:///session``), mapping user/group IDs is available > > +(since libvirt version TBD). After reserving an ID range from the host for your > > +regular user > > Is the GUID/GID mapping available as in optional, or available as > in mandatory ? > In this series, optional. My reasoning was that someone might want to not do it and would prefer to run virtiofsd as their own user. On second thought, that is not what accessmode='passthrough' means, so for non-mapping non-privileged use, a different/new accessmode attribute will be needed. > I would expect libvirt to "do the right thing" and automatically load > the /etc/subuid data for the current user and NOT require any extra > XML mapping to be set for unprivileged usage. > So, by default libvirt would assume that unprivileged accessmode='passthrough' means "use the whole range for my user from /etc/subuid"? Podman treats /etc/subuid as a pool and chooses a 64K range that is (to its knowledge) unused. I'm undecided whether that would also be a reasonable option for a default.