Re: [libvirt PATCHv1 8/8] docs: virtiofs: add section about ID remapping
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 :|
Re: [libvirt PATCHv1 8/8] docs: virtiofs: add section about ID remapping
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 :|
Re: [libvirt PATCHv1 8/8] docs: virtiofs: add section about ID remapping
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 :| signature.asc Description: PGP signature
Re: [libvirt PATCHv1 8/8] docs: virtiofs: add section about ID remapping
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 > > > --- > > > 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 :|
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 --- 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 signature.asc Description: PGP signature
Re: [libvirt PATCHv1 8/8] docs: virtiofs: add section about ID remapping
On Mon, Sep 11, 2023 at 03:51:28PM +0200, Ján Tomko wrote: > Signed-off-by: Ján Tomko > --- > 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:10:65536 > + $ cat /etc/subgid > + jtomko:10:65536 > + > +you can let virtiofsd map guest UIDs from 0 to 65535 > +to host IDs 10 to 165535 for example: > + > +:: > + > + > + > +... > + > + > + > + > + > + > + > 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 :|
