On Fri, Nov 08, 2019 at 10:47:52AM +0100, Jiri Denemark wrote:
On Fri, Nov 08, 2019 at 15:00:22 +0800, Han Han wrote:
> Signed-off-by: Han Han <hhan(a)redhat.com>
> ---
> docs/news.xml | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/docs/news.xml b/docs/news.xml
> index 571a1b6ea4..c37d0d22ef 100644
> --- a/docs/news.xml
> +++ b/docs/news.xml
> @@ -199,6 +199,16 @@
> backend. It requires qemu over <code>4.1</code>.
> </description>
> </change>
> + <change>
> + <summary>
> + Introduce virConnectSetIdentity API
> + </summary>
> + <description>
> + For splited libvirt daemons, this API can be used to forward uid, gid
> + and selinux info from <code>virproxyd</code> to
> + <code>virtqemud</code>.
> + </description>
> + </change>
> </section>
> <section title="Improvements">
> <change>
This API is not really supposed to be used by users. It's an internal
implementation detail and should not be mentioned in news.
Sort of. While the immediate motivation is for internal use, I can
imagine scenarios where mgmt apps might want to use this too. It
applies to any case where one process connecting to libvirt is doing
work on behalf of a user with different privileges.
Consider a web app running under httpd account, but authenticating
its client users. It wants libvirt APIs it invokes to have access
control checks done against the web client user's identity instead
of its own. It would be appropriate for the app to use the new
virConnectSetIdentity API call in this case.
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 :|