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@xxxxxxxxxx> > > --- > > 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
