Signed-off-by: Ján Tomko <jtomko@redhat.com>
---
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
+
+::
+
+ $ cat /etc/subuid
+ jtomko:100000:65536
+ $ cat /etc/subgid
+ jtomko:100000:65536
+
+you can let virtiofsd map guest UIDs from 0 to 65535
+to host IDs 100000 to 165535 for example:
+
+::
+
+ <filesystem type='mount' accessmode='passthrough'>
+ <driver type='virtiofs' queue='1024'/>
+ ...
+ <idmap>
+ <uid start='0' target='100000' count='65535'/>
+ <gid start='0' target='100000' count='65535'/>
+ </idmap>
+ </filesystem>
+
+
Optional parameters
===================
--
2.41.0
On Mon, Sep 11, 2023 at 03:51:28PM +0200, Ján Tomko wrote: > Signed-off-by: Ján Tomko <jtomko@redhat.com> > --- > 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 ? 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. By all means have an XML config for it, but it should be optional and something that is essentially never used except for niche scenarios > + > +:: > + > + $ cat /etc/subuid > + jtomko:100000:65536 > + $ cat /etc/subgid > + jtomko:100000:65536 > + > +you can let virtiofsd map guest UIDs from 0 to 65535 > +to host IDs 100000 to 165535 for example: > + > +:: > + > + <filesystem type='mount' accessmode='passthrough'> > + <driver type='virtiofs' queue='1024'/> > + ... > + <idmap> > + <uid start='0' target='100000' count='65535'/> > + <gid start='0' target='100000' count='65535'/> > + </idmap> > + </filesystem> > + > + > Optional parameters > =================== > > -- > 2.41.0 > With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
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@redhat.com> >> --- >> 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. Jano >By all means have an XML config for it, but it should be optional and >something that is essentially never used except for niche scenarios >
On Tue, Sep 12, 2023 at 04:05:04PM +0200, Ján Tomko wrote:
> 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@redhat.com>
> > > ---
> > > 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.
I thought podman simply used the entry that is in /etc/subuid
as is:
$ grep $LOGNAME /etc/subuid
berrange:165536:65536
$ podman run -it centos:stream9 cat /proc/self/uid_map
0 1001 1
1 165536 65536
Maps "root" to my original unpriv login UID, and maps
everything else to the 64k IDs reserved in /etc/subuid
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On a Tuesday in 2023, Daniel P. Berrangé wrote: >On Tue, Sep 12, 2023 at 04:05:04PM +0200, Ján Tomko wrote: >> On a Monday in 2023, Daniel P. Berrangé wrote: >> > 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. > >I thought podman simply used the entry that is in /etc/subuid >as is: D'oh. Right. By default it uses --userns=host, which behaves as you describe. What I described is --userns=auto behavior, suggested in the bug discussion: https://bugzilla.redhat.com/show_bug.cgi?id=2034630#c8 Jano > >$ grep $LOGNAME /etc/subuid >berrange:165536:65536 >$ podman run -it centos:stream9 cat /proc/self/uid_map > 0 1001 1 > 1 165536 65536 > > >Maps "root" to my original unpriv login UID, and maps >everything else to the 64k IDs reserved in /etc/subuid > > >With regards, >Daniel >-- >|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| >|: https://libvirt.org -o- https://fstop138.berrange.com :| >|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| >
On Wed, Sep 13, 2023 at 05:07:27PM +0200, Ján Tomko wrote: > On a Tuesday in 2023, Daniel P. Berrangé wrote: > > On Tue, Sep 12, 2023 at 04:05:04PM +0200, Ján Tomko wrote: > > > On a Monday in 2023, Daniel P. Berrangé wrote: > > > > 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. > > > > I thought podman simply used the entry that is in /etc/subuid > > as is: > > D'oh. Right. By default it uses --userns=host, which behaves as you > describe. > > What I described is --userns=auto behavior, suggested in the bug > discussion: > https://bugzilla.redhat.com/show_bug.cgi?id=2034630#c8 What I'm also missing is understanding what component enforces that you have grabbed a range that is actually present for your user in /etc/subuid, as opposed to grabbing a range belonging to a different user. Something must enforce that otherwise it is a total free for all and /etc/subuid is largely pointless. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Wed, Sep 13, 2023 at 04:14:55PM +0100, Daniel P. Berrangé wrote: > On Wed, Sep 13, 2023 at 05:07:27PM +0200, Ján Tomko wrote: > > On a Tuesday in 2023, Daniel P. Berrangé wrote: > > > On Tue, Sep 12, 2023 at 04:05:04PM +0200, Ján Tomko wrote: > > > > On a Monday in 2023, Daniel P. Berrangé wrote: > > > > > 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. > > > > > > I thought podman simply used the entry that is in /etc/subuid > > > as is: > > > > D'oh. Right. By default it uses --userns=host, which behaves as you > > describe. > > > > What I described is --userns=auto behavior, suggested in the bug > > discussion: > > https://bugzilla.redhat.com/show_bug.cgi?id=2034630#c8 > > What I'm also missing is understanding what component enforces that > you have grabbed a range that is actually present for your user > in /etc/subuid, as opposed to grabbing a range belonging to a > different user. > > Something must enforce that otherwise it is a total free for all > and /etc/subuid is largely pointless. Ah, virtiofsd is invoking newuidmap, which is a program with the 'setuid' capability flag set on its binary. This lets us do the privileged /proc/uidmap setup on behalf of virtiofsd and validates the /etc/subuid ranges. I think libvirt could, by default, read /etc/subuid and pick a 64k range from it, if it had more than 64k available. In future we could track the ranges to keep them unique per instance, but for now even the simple picking is better than requiring a manua user config every time. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
© 2016 - 2024 Red Hat, Inc.