Change isHyperVAdminMember from returning a bool to returning an error so that callers surface the specific failure reason — particularly distinguishing "not in the group" from "in the group but session not updated" (new ErrHypervUserSessionNotUpdated sentinel). This gives users actionable guidance instead of a generic permission error.
Signed-off-by: lstocchi <lstocchi@redhat.com>
Introducing a new `podmand system` subcommand to prepare a Windows host
to run Hyper-V based Podman machines: `hyperv-prep`.
When executed it:
- creates of the registry keys for VSocks
- adds the current user to the Hyper-V administrators group
This command requires an administrator terminal.
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
The podman module paths are moving from github.com/containers/podman to
go.podman.io/podman. This will help with future mobility.
Signed-off-by: Brent Baude <bbaude@redhat.com>
Currently, running Podman on Hyper-V as a non-administrator requires the user to be a member of the "Hyper-V Administrators" local group. If they are not, various WMI calls fail with access denied.
This commit automates the permission setup.
1. During podman machine init, if Podman is running with elevated privileges (required for registry/networking setup anyway), it will now automatically add the current user to the localized "Hyper-V Administrators" group
2. If a user is added to the group, the change is not reflected until the next login. We now detect this state and explicitly instruct the user to log out and back in.
3. Modified the Hyper-V stubber to handle permission checks at the method level rather than the provider selection level (GetAll). This allows init to continue far enough to perform the elevation and setting.
Signed-off-by: lstocchi <lstocchi@redhat.com>
Podman 5.x and earlier required to run as admin to work with Hyper-v.
Starting from Podman 6 this is not mandatory anymore as Registry
entries are handled differently. However, it may
happen the user have a legacy machine running when switching to Podman 6
or starts an old machine in elevated mode and then tries to stop it as a
normal user with Podman 6. If that happens the system will end up in a corrupted state
as the gvproxy process will not be stopped.
To prevent such scenario and issues, this commit maintains the original
behavior Podman 5.x has. Legacy Hyper-v machines needs to be handled
with elevated rights.
Signed-off-by: lstocchi <lstocchi@redhat.com>
Update GetAll() and GetByVMType() to add a check to prevent non hyper-v admin users to
interact with hyperv machines.
Users can work with hyperv machines only with elevated rights or if
members of the hyperv administrators group
Signed-off-by: lstocchi <lstocchi@redhat.com>
Previously, each new HyperV Podman machine required creating new hvsock
registry entries, necessitating administrator privileges.
This change modifies the HyperV provider to reuse existing hvsock
entries if found. This is possible due to Podman's current
limitation of running only one HyperV machine at a time.
As a result, administrator privileges are only needed for the first initial
machine setup (when the registry is empty). Subsequent machines can be created by users in the
"Hyper-V Administrators" group without being Admin.
Hvsock entries are no longer deleted on each machine removal; cleanup
is handled when the last machine gets removed.
Signed-off-by: lstocchi <lstocchi@redhat.com>
