Re: [PATCH v2] qemu-options: Deprecate "-runas" and introduce "-run-with user=..." instead
On Mon, May 6, 2024 at 1:21 PM Thomas Huth wrote:
>
> The old "-runas" option has the disadvantage that it is not visible
> in the QAPI schema, so it is not available via the normal introspection
> mechanisms. We've recently introduced the "-run-with" option for exactly
> this purpose, which is meant to handle the options that affect the
> runtime behavior. Thus let's introduce a "user=..." parameter here now
> and deprecate the old "-runas" option.
No need to deprecate it, there are other shortcut options that are
just a couple lines of code to implement:
case QEMU_OPTION_watchdog_action: {
opts = qemu_opts_create(qemu_find_opts("action"),
NULL, 0, _abort);
qemu_opt_set(opts, "watchdog", optarg, _abort);
break;
However that would be a larger patch, basically moving all of the
--run-with handling to qemu_process_early_options() (and, as an aside,
setting .merge_lists = true in qemu_run_with_opts).
No objections to your patch, but also no objections to cleaning all of
--run-with; I should have caught it and proposed the shortcut options
when it was introduced or when --chroot was removed.
Paolo
> if (!os_set_runas(optarg)) {
> error_report("User \"%s\" doesn't exist"
> " (and is not :)",
> @@ -3612,6 +3617,16 @@ void qemu_init(int argc, char **argv)
> if (str) {
> os_set_chroot(str);
> }
> +str = qemu_opt_get(opts, "user");
> +if (str) {
> +if (!os_set_runas(str)) {
> +error_report("User \"%s\" doesn't exist"
> + " (and is not :)",
> + optarg);
> +exit(1);
> +}
> +}
> +
> break;
> }
> #endif /* CONFIG_POSIX */
> diff --git a/qemu-options.hx b/qemu-options.hx
> index cf61f6b863..3031479a15 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -4824,7 +4824,8 @@ DEF("runas", HAS_ARG, QEMU_OPTION_runas, \
> SRST
> ``-runas user``
> Immediately before starting guest execution, drop root privileges,
> -switching to the specified user.
> +switching to the specified user. This option is deprecated, use
> +``-run-with user=...`` instead.
> ERST
>
> DEF("prom-env", HAS_ARG, QEMU_OPTION_prom_env,
> @@ -4990,13 +4991,15 @@ DEF("qtest-log", HAS_ARG, QEMU_OPTION_qtest_log, "",
> QEMU_ARCH_ALL)
>
> #ifdef CONFIG_POSIX
> DEF("run-with", HAS_ARG, QEMU_OPTION_run_with,
> -"-run-with [async-teardown=on|off][,chroot=dir]\n"
> +"-run-with [async-teardown=on|off][,chroot=dir][user=username|uid:gid]\n"
> "Set miscellaneous QEMU process lifecycle options:\n"
> "async-teardown=on enables asynchronous teardown (Linux
> only)\n"
> -"chroot=dir chroot to dir just before starting the VM\n",
> +"chroot=dir chroot to dir just before starting the VM\n"
> +"user=username switch to the specified user before
> starting the VM\n"
> +"user=uid:gid dito, but use specified user-ID and
> group-ID instead\n",
> QEMU_ARCH_ALL)
> SRST
> -``-run-with [async-teardown=on|off][,chroot=dir]``
> +``-run-with [async-teardown=on|off][,chroot=dir][user=username|uid:gid]``
> Set QEMU process lifecycle options.
>
> ``async-teardown=on`` enables asynchronous teardown. A new process called
> @@ -5013,6 +5016,10 @@ SRST
> ``chroot=dir`` can be used for doing a chroot to the specified directory
> immediately before starting the guest execution. This is especially
> useful
> in combination with -runas.
> +
> +``user=username`` or ``user=uid:gid`` can be used to drop root privileges
> +by switching to the specified user (via username) or user and group
> +(via uid:gid) immediately before starting guest execution.
> ERST
> #endif
>
> --
> 2.45.0
>M
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org
Re: [PATCH for-9.0] docs/about: Mark the iaspc machine type as deprecated
Il mer 27 mar 2024, 14:09 Igor Mammedov ha scritto: > It's question of whether we are willing to do unthinkable, > i.e. to break QEMU <-> guest ABI for isapc case by removing > corresponding fwcfg entries. > It's not unthinkable since it's unversioned. we are loosing a chance to cleanup > QEMU code base touching following > > m->option_rom_has_mr = true; > m->rom_file_has_mr = false; > pcmc->pci_enabled = false; > pcmc->has_acpi_build = false; > pcmc->smbios_defaults = false; > pcmc->gigabyte_align = false; > pcmc->smbios_legacy_mode = true; pcmc->has_reserved_memory > = false; > Some of these can go away, for the others probably we can think of making isapc a direct subclass of X86MachineState. I would rather keep it because it's the only way to test userspace interrupt injection in KVM. Paolo they are all marginal but in shared code, and removing them > makes code a bit more easier to follow (especially when it > comes to memory layout). > > > With regards, > > Daniel > > ___ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-le...@lists.libvirt.org
Re: Patches on libvirt patchew are outdated
On Mon, Dec 18, 2023 at 2:14 PM Peter Krempa wrote: > The patches are now picked up, but I've noticed that all series' are > marked as "does not apply to master". > > Unfortunately the new mailing list (mailman3 + hyperkitty) has a bad > habit of touching all the patches. Very specifically it recodes and > quotes CRLF, which makes it impossible to apply via 'git am' in default > configuration and requires using 'git am --quoted-cr=strip'. This > applies both in mail and also in archives. No, that was just a typo when switching away from git:// as the protocol used to fetch from the upstream repo. If you see a series where Mailman3's re-encoding is an issue please let me know, but I have reset most series now and they applied fine. Paolo ___ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-le...@lists.libvirt.org
Re: Patches on libvirt patchew are outdated
On Mon, Dec 18, 2023 at 9:33 AM Paolo Bonzini wrote: > > On Mon, Dec 18, 2023 at 9:32 AM Peter Krempa wrote: > > > > On Mon, Dec 18, 2023 at 14:42:57 +0800, Han Han wrote: > > > Hi, > > > The libvirt patchew https://patchew.org/Libvirt/ has no update for more > > > than one month. Is it dropped? If not, please sync the patches to it~ > > > > The problem is likely caused by the switch to the new mailing list. The > > patch importer of patchew wasn't probably configured to use the new > > list. > > > > Since the patchew project doesn't seem to contain the actual > > configuration for the importer that is used on patchew.org we'll need to > > contact somebody to fix it. > > > > Paolo, Daniel, do you know who can fix this? > > Either I or Fam can fix it. We just need to subscribe to the new mailing list. On top of that, the last month of patches was delivered, but not processed because Patchew did not recognize devel@lists.libvirt.org as a message for the Libvirt project. This will also sort itself out in an hour or so. Paolo ___ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-le...@lists.libvirt.org
Re: Patches on libvirt patchew are outdated
On Mon, Dec 18, 2023 at 9:32 AM Peter Krempa wrote: > > On Mon, Dec 18, 2023 at 14:42:57 +0800, Han Han wrote: > > Hi, > > The libvirt patchew https://patchew.org/Libvirt/ has no update for more > > than one month. Is it dropped? If not, please sync the patches to it~ > > The problem is likely caused by the switch to the new mailing list. The > patch importer of patchew wasn't probably configured to use the new > list. > > Since the patchew project doesn't seem to contain the actual > configuration for the importer that is used on patchew.org we'll need to > contact somebody to fix it. > > Paolo, Daniel, do you know who can fix this? Either I or Fam can fix it. We just need to subscribe to the new mailing list. Paolo ___ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-le...@lists.libvirt.org
