On 03/06/2013 05:49 AM, Daniel P. Berrange wrote:
From: "Daniel P. Berrange" <berrange@redhat.com>
A socket object has various pieces of security data associated with it, such as the SELinux context, the SASL username and the x509 distinguished name. Add new APIs to virNetServerClient and related modules to access this data.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- src/libvirt_private.syms | 6 ++++++ src/rpc/virnetserverclient.c | 46 ++++++++++++++++++++++++++++++++++++++++++++ src/rpc/virnetserverclient.h | 7 +++++++ src/rpc/virnetsocket.c | 44 ++++++++++++++++++++++++++++++++++++++++++ src/rpc/virnetsocket.h | 2 ++ src/rpc/virnettlscontext.c | 18 +++++++++++++++++ src/rpc/virnettlscontext.h | 2 ++ 7 files changed, 125 insertions(+)
+++ b/src/rpc/virnetserverclient.c @@ -587,6 +587,16 @@ bool virNetServerClientHasTLSSession(virNetServerClientPtr client) return has; }
+ +virNetTLSSessionPtr virNetServerClientGetTLSSession(virNetServerClientPtr client) +{ + virNetTLSSessionPtr tls; + virObjectLock(client); + tls = client->tls; + virObjectUnlock(client); + return tls; +}
This needs to be guarded by WITH_GNUTLS (since client->tls doesn't exist otherwise). Which in turn may affect your libvirt_private.syms if you don't create a counterpart stub function.
+ + +virNetSASLSessionPtr virNetServerClientGetSASLSession(virNetServerClientPtr client) +{ + virNetSASLSessionPtr sasl; + virObjectLock(client); + sasl = client->sasl; + virObjectUnlock(client); + return sasl; +} #endif
This function was inside an #ifdef, but you declared it in libvirt_private.syms, so you'd need a counterpart stub function. Shoot, ran out of review time halfway through. Overall the idea looks sound, though. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org