External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2025-01-05 20:45:18 +00:00
Code Issues Packages Projects Releases Wiki Activity
f49a5e3bf4
libvirt/src/rpc/virnetserverclient.h

176 lines
8.0 KiB
C
Raw Normal View History

Introduce generic RPC server objects To facilitate creation of new daemons providing XDR RPC services, pull a lot of the libvirtd daemon code into a set of reusable objects. * virNetServer: A server contains one or more services which accept incoming clients. It maintains the list of active clients. It has a list of RPC programs which can be used by clients. When clients produce a complete RPC message, the server passes this onto the corresponding program for handling, and queues any response back with the client. * virNetServerClient: Encapsulates a single client connection. All I/O for the client is handled, reading & writing RPC messages. * virNetServerProgram: Handles processing and dispatch of RPC method calls for a single RPC (program,version). Multiple programs can be registered with the server. * virNetServerService: Encapsulates socket(s) listening for new connections. Each service listens on a single host/port, but may have multiple sockets if on a dual IPv4/6 host. Each new daemon now merely has to define the list of RPC procedures & their handlers. It does not need to deal with any network related functionality at all.
2010-12-01 16:36:40 +00:00
/*
* virnetserverclient.h: generic network RPC server client
*
* Copyright (C) 2006-2011 Red Hat, Inc.
* Copyright (C) 2006 Daniel P. Berrange
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
maint: fix up copyright notice inconsistencies https://www.gnu.org/licenses/gpl-howto.html recommends that the 'If not, see <url>.' phrase be a separate sentence. * tests/securityselinuxhelper.c: Remove doubled line. * tests/securityselinuxtest.c: Likewise. * globally: s/; If/. If/
2012-09-20 22:30:55 +00:00
* License along with this library. If not, see
Desert the FSF address in copyright Per the FSF address could be changed from time to time, and GNU recommends the following now: (http://www.gnu.org/licenses/gpl-howto.html) You should have received a copy of the GNU General Public License along with Foobar. If not, see <http://www.gnu.org/licenses/>. This patch removes the explicit FSF address, and uses above instead (of course, with inserting 'Lesser' before 'General'). Except a bunch of files for security driver, all others are changed automatically, the copyright for securify files are not complete, that's why to do it manually: src/security/security_selinux.h src/security/security_driver.h src/security/security_selinux.c src/security/security_apparmor.h src/security/security_apparmor.c src/security/security_driver.c
2012-07-21 10:06:23 +00:00
* <http://www.gnu.org/licenses/>.
Introduce generic RPC server objects To facilitate creation of new daemons providing XDR RPC services, pull a lot of the libvirtd daemon code into a set of reusable objects. * virNetServer: A server contains one or more services which accept incoming clients. It maintains the list of active clients. It has a list of RPC programs which can be used by clients. When clients produce a complete RPC message, the server passes this onto the corresponding program for handling, and queues any response back with the client. * virNetServerClient: Encapsulates a single client connection. All I/O for the client is handled, reading & writing RPC messages. * virNetServerProgram: Handles processing and dispatch of RPC method calls for a single RPC (program,version). Multiple programs can be registered with the server. * virNetServerService: Encapsulates socket(s) listening for new connections. Each service listens on a single host/port, but may have multiple sockets if on a dual IPv4/6 host. Each new daemon now merely has to define the list of RPC procedures & their handlers. It does not need to deal with any network related functionality at all.
2010-12-01 16:36:40 +00:00
*
* Author: Daniel P. Berrange <berrange@redhat.com>
*/
#ifndef __VIR_NET_SERVER_CLIENT_H__
# define __VIR_NET_SERVER_CLIENT_H__
Add ability to get a virIdentity from a virNetServerClientPtr Add APIs which allow creation of a virIdentity from the info associated with a virNetServerClientPtr instance. This is done based on the results of client authentication processes like TLS, x509, SASL, SO_PEERCRED Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-01-23 15:05:01 +00:00
# include "viridentity.h"
Introduce generic RPC server objects To facilitate creation of new daemons providing XDR RPC services, pull a lot of the libvirtd daemon code into a set of reusable objects. * virNetServer: A server contains one or more services which accept incoming clients. It maintains the list of active clients. It has a list of RPC programs which can be used by clients. When clients produce a complete RPC message, the server passes this onto the corresponding program for handling, and queues any response back with the client. * virNetServerClient: Encapsulates a single client connection. All I/O for the client is handled, reading & writing RPC messages. * virNetServerProgram: Handles processing and dispatch of RPC method calls for a single RPC (program,version). Multiple programs can be registered with the server. * virNetServerService: Encapsulates socket(s) listening for new connections. Each service listens on a single host/port, but may have multiple sockets if on a dual IPv4/6 host. Each new daemon now merely has to define the list of RPC procedures & their handlers. It does not need to deal with any network related functionality at all.
2010-12-01 16:36:40 +00:00
# include "virnetsocket.h"
# include "virnetmessage.h"
Turn virNetServer* into virObject instances Make all the virNetServer* objects use the virObject APIs for reference counting Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-07-11 13:35:52 +00:00
# include "virobject.h"
Rename json.{c,h} to virjson.{c,h}
2012-12-12 17:53:50 +00:00
# include "virjson.h"
Introduce generic RPC server objects To facilitate creation of new daemons providing XDR RPC services, pull a lot of the libvirtd daemon code into a set of reusable objects. * virNetServer: A server contains one or more services which accept incoming clients. It maintains the list of active clients. It has a list of RPC programs which can be used by clients. When clients produce a complete RPC message, the server passes this onto the corresponding program for handling, and queues any response back with the client. * virNetServerClient: Encapsulates a single client connection. All I/O for the client is handled, reading & writing RPC messages. * virNetServerProgram: Handles processing and dispatch of RPC method calls for a single RPC (program,version). Multiple programs can be registered with the server. * virNetServerService: Encapsulates socket(s) listening for new connections. Each service listens on a single host/port, but may have multiple sockets if on a dual IPv4/6 host. Each new daemon now merely has to define the list of RPC procedures & their handlers. It does not need to deal with any network related functionality at all.
2010-12-01 16:36:40 +00:00
rpc: pass virNetServer to post-exec restart callback in typesafe manner The virNetServer class is passing a pointer to itself to the virNetServerClient as a 'void *' pointer. This is presumably due to fact that the virnetserverclient.h file doesn't see the virNetServerPtr typedef. The typedef is easily movable though, which lets us get typesafe parameter passing, removing the confusion of passing two distinct 'void *' pointers to one method. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2018-01-19 17:41:13 +00:00
typedef struct _virNetServer virNetServer;
typedef virNetServer *virNetServerPtr;
Introduce generic RPC server objects To facilitate creation of new daemons providing XDR RPC services, pull a lot of the libvirtd daemon code into a set of reusable objects. * virNetServer: A server contains one or more services which accept incoming clients. It maintains the list of active clients. It has a list of RPC programs which can be used by clients. When clients produce a complete RPC message, the server passes this onto the corresponding program for handling, and queues any response back with the client. * virNetServerClient: Encapsulates a single client connection. All I/O for the client is handled, reading & writing RPC messages. * virNetServerProgram: Handles processing and dispatch of RPC method calls for a single RPC (program,version). Multiple programs can be registered with the server. * virNetServerService: Encapsulates socket(s) listening for new connections. Each service listens on a single host/port, but may have multiple sockets if on a dual IPv4/6 host. Each new daemon now merely has to define the list of RPC procedures & their handlers. It does not need to deal with any network related functionality at all.
2010-12-01 16:36:40 +00:00
typedef struct _virNetServerClient virNetServerClient;
typedef virNetServerClient *virNetServerClientPtr;
rpc: simplify calling convention of virNetServerClientDispatchFunc Currently virNetServerClientDispatchFunc implementations are only responsible for free'ing the "msg" parameter upon success. Simplify the calling convention by making it their unconditional responsibility to free the "msg", and close the client if desired. Reviewed-by: John Ferlan <jferlan@redhat.com> Reviewed-by: Jim Fehlig <jfehlig@suse.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-03-06 16:44:34 +00:00
/* This function owns the "msg" pointer it is passed and
* must arrange for virNetMessageFree to be called on it
*/
typedef void (*virNetServerClientDispatchFunc)(virNetServerClientPtr client,
virNetMessagePtr msg,
void *opaque);
Introduce generic RPC server objects To facilitate creation of new daemons providing XDR RPC services, pull a lot of the libvirtd daemon code into a set of reusable objects. * virNetServer: A server contains one or more services which accept incoming clients. It maintains the list of active clients. It has a list of RPC programs which can be used by clients. When clients produce a complete RPC message, the server passes this onto the corresponding program for handling, and queues any response back with the client. * virNetServerClient: Encapsulates a single client connection. All I/O for the client is handled, reading & writing RPC messages. * virNetServerProgram: Handles processing and dispatch of RPC method calls for a single RPC (program,version). Multiple programs can be registered with the server. * virNetServerService: Encapsulates socket(s) listening for new connections. Each service listens on a single host/port, but may have multiple sockets if on a dual IPv4/6 host. Each new daemon now merely has to define the list of RPC procedures & their handlers. It does not need to deal with any network related functionality at all.
2010-12-01 16:36:40 +00:00
typedef int (*virNetServerClientFilterFunc)(virNetServerClientPtr client,
virNetMessagePtr msg,
void *opaque);
rpc: clarify "void *" values passed to client callbacks Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2018-01-19 17:24:03 +00:00
/*
* @data: value allocated by virNetServerClintPrivNew(PostExecRestart) callback
*/
Add JSON serialization of virNetServerClientPtr objects for process re-exec() Add two new APIs virNetServerClientNewPostExecRestart and virNetServerClientPreExecRestart which allow a virNetServerClientPtr object to be created from a JSON object and saved to a JSON object, for the purpose of re-exec'ing a process. This includes serialization of the connected socket associated with the client Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-09 11:54:54 +00:00
typedef virJSONValuePtr (*virNetServerClientPrivPreExecRestart)(virNetServerClientPtr client,
void *data);
rpc: clarify "void *" values passed to client callbacks Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2018-01-19 17:24:03 +00:00
/*
* @opaque: value of @privOpaque from virNetServerClientNewPostExecRestart
*/
Add JSON serialization of virNetServerClientPtr objects for process re-exec() Add two new APIs virNetServerClientNewPostExecRestart and virNetServerClientPreExecRestart which allow a virNetServerClientPtr object to be created from a JSON object and saved to a JSON object, for the purpose of re-exec'ing a process. This includes serialization of the connected socket associated with the client Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-09 11:54:54 +00:00
typedef void *(*virNetServerClientPrivNewPostExecRestart)(virNetServerClientPtr client,
virJSONValuePtr object,
void *opaque);
rpc: clarify "void *" values passed to client callbacks Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2018-01-19 17:24:03 +00:00
/*
* @opaque: value of @privOpaque from virNetServerClientNew
*/
Refactor RPC client private data setup Currently there is a hook function that is invoked when a new client connection comes in, which allows an app to setup private data. This setup will make it difficult to serialize client state during process re-exec(). Change to a model where the app registers a callback when creating the virNetServerPtr instance, which is used to allocate the client private data immediately during virNetClientPtr construction. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-09 11:31:34 +00:00
typedef void *(*virNetServerClientPrivNew)(virNetServerClientPtr client,
void *opaque);
rpc: virnetserverclient: Identify clients by an integer ID Admin API needs a way of addressing specific clients. Unlike servers, which we are happy to address by names both because its name reflects its purpose (to some extent) and we only have two of them (so far), naming clients doesn't make any sense, since a) each client is an anonymous, i.e. not recognized after a disconnect followed by a reconnect, b) we can't predict what kind of requests it's going to send to daemon, and c) the are loads of them comming and going, so the only viable option is to use an ID which is of a reasonably wide data type. Signed-off-by: Erik Skultety <eskultet@redhat.com>
2016-04-13 18:54:40 +00:00
virNetServerClientPtr virNetServerClientNew(unsigned long long id,
virNetSocketPtr sock,
Introduce generic RPC server objects To facilitate creation of new daemons providing XDR RPC services, pull a lot of the libvirtd daemon code into a set of reusable objects. * virNetServer: A server contains one or more services which accept incoming clients. It maintains the list of active clients. It has a list of RPC programs which can be used by clients. When clients produce a complete RPC message, the server passes this onto the corresponding program for handling, and queues any response back with the client. * virNetServerClient: Encapsulates a single client connection. All I/O for the client is handled, reading & writing RPC messages. * virNetServerProgram: Handles processing and dispatch of RPC method calls for a single RPC (program,version). Multiple programs can be registered with the server. * virNetServerService: Encapsulates socket(s) listening for new connections. Each service listens on a single host/port, but may have multiple sockets if on a dual IPv4/6 host. Each new daemon now merely has to define the list of RPC procedures & their handlers. It does not need to deal with any network related functionality at all.
2010-12-01 16:36:40 +00:00
int auth,
bool readonly,
Fix hardcoded limit on client requests in RPC code The virNetServerClient object had a hardcoded limit of 10 requests per client. Extend constructor to allow it to be passed in as a configurable variable. Wire this up to the 'max_client_requests' config parameter in libvirtd * daemon/libvirtd.c: Pass max_client_requests into services * src/rpc/virnetserverservice.c, src/rpc/virnetserverservice.h: Pass nrequests_client_max to clients * src/rpc/virnetserverclient.c, src/rpc/virnetserverclient.h: Allow configurable request limit
2011-06-30 10:45:55 +00:00
size_t nrequests_max,
Refactor RPC client private data setup Currently there is a hook function that is invoked when a new client connection comes in, which allows an app to setup private data. This setup will make it difficult to serialize client state during process re-exec(). Change to a model where the app registers a callback when creating the virNetServerPtr instance, which is used to allocate the client private data immediately during virNetClientPtr construction. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-09 11:31:34 +00:00
virNetTLSContextPtr tls,
virNetServerClientPrivNew privNew,
Add JSON serialization of virNetServerClientPtr objects for process re-exec() Add two new APIs virNetServerClientNewPostExecRestart and virNetServerClientPreExecRestart which allow a virNetServerClientPtr object to be created from a JSON object and saved to a JSON object, for the purpose of re-exec'ing a process. This includes serialization of the connected socket associated with the client Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-09 11:54:54 +00:00
virNetServerClientPrivPreExecRestart privPreExecRestart,
Refactor RPC client private data setup Currently there is a hook function that is invoked when a new client connection comes in, which allows an app to setup private data. This setup will make it difficult to serialize client state during process re-exec(). Change to a model where the app registers a callback when creating the virNetServerPtr instance, which is used to allocate the client private data immediately during virNetClientPtr construction. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-09 11:31:34 +00:00
virFreeCallback privFree,
rpc: annotate various parameters as being required to be non-NULL The server name and client data callbacks need to be non-NULL or the system will crash at various times. This is particularly bad when some of the crashes only occur post-exec restart. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2018-01-23 13:02:06 +00:00
void *privOpaque)
ATTRIBUTE_NONNULL(2) ATTRIBUTE_NONNULL(7) ATTRIBUTE_NONNULL(9);
Introduce generic RPC server objects To facilitate creation of new daemons providing XDR RPC services, pull a lot of the libvirtd daemon code into a set of reusable objects. * virNetServer: A server contains one or more services which accept incoming clients. It maintains the list of active clients. It has a list of RPC programs which can be used by clients. When clients produce a complete RPC message, the server passes this onto the corresponding program for handling, and queues any response back with the client. * virNetServerClient: Encapsulates a single client connection. All I/O for the client is handled, reading & writing RPC messages. * virNetServerProgram: Handles processing and dispatch of RPC method calls for a single RPC (program,version). Multiple programs can be registered with the server. * virNetServerService: Encapsulates socket(s) listening for new connections. Each service listens on a single host/port, but may have multiple sockets if on a dual IPv4/6 host. Each new daemon now merely has to define the list of RPC procedures & their handlers. It does not need to deal with any network related functionality at all.
2010-12-01 16:36:40 +00:00
rpc: pass virNetServer to post-exec restart callback in typesafe manner The virNetServer class is passing a pointer to itself to the virNetServerClient as a 'void *' pointer. This is presumably due to fact that the virnetserverclient.h file doesn't see the virNetServerPtr typedef. The typedef is easily movable though, which lets us get typesafe parameter passing, removing the confusion of passing two distinct 'void *' pointers to one method. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2018-01-19 17:41:13 +00:00
virNetServerClientPtr virNetServerClientNewPostExecRestart(virNetServerPtr srv,
virJSONValuePtr object,
Add JSON serialization of virNetServerClientPtr objects for process re-exec() Add two new APIs virNetServerClientNewPostExecRestart and virNetServerClientPreExecRestart which allow a virNetServerClientPtr object to be created from a JSON object and saved to a JSON object, for the purpose of re-exec'ing a process. This includes serialization of the connected socket associated with the client Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-09 11:54:54 +00:00
virNetServerClientPrivNewPostExecRestart privNew,
virNetServerClientPrivPreExecRestart privPreExecRestart,
virFreeCallback privFree,
rpc: annotate various parameters as being required to be non-NULL The server name and client data callbacks need to be non-NULL or the system will crash at various times. This is particularly bad when some of the crashes only occur post-exec restart. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2018-01-23 13:02:06 +00:00
void *privOpaque)
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2) ATTRIBUTE_NONNULL(3)
ATTRIBUTE_NONNULL(4) ATTRIBUTE_NONNULL(5);
Add JSON serialization of virNetServerClientPtr objects for process re-exec() Add two new APIs virNetServerClientNewPostExecRestart and virNetServerClientPreExecRestart which allow a virNetServerClientPtr object to be created from a JSON object and saved to a JSON object, for the purpose of re-exec'ing a process. This includes serialization of the connected socket associated with the client Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-08-09 11:54:54 +00:00
virJSONValuePtr virNetServerClientPreExecRestart(virNetServerClientPtr client);
Introduce generic RPC server objects To facilitate creation of new daemons providing XDR RPC services, pull a lot of the libvirtd daemon code into a set of reusable objects. * virNetServer: A server contains one or more services which accept incoming clients. It maintains the list of active clients. It has a list of RPC programs which can be used by clients. When clients produce a complete RPC message, the server passes this onto the corresponding program for handling, and queues any response back with the client. * virNetServerClient: Encapsulates a single client connection. All I/O for the client is handled, reading & writing RPC messages. * virNetServerProgram: Handles processing and dispatch of RPC method calls for a single RPC (program,version). Multiple programs can be registered with the server. * virNetServerService: Encapsulates socket(s) listening for new connections. Each service listens on a single host/port, but may have multiple sockets if on a dual IPv4/6 host. Each new daemon now merely has to define the list of RPC procedures & their handlers. It does not need to deal with any network related functionality at all.
2010-12-01 16:36:40 +00:00
int virNetServerClientAddFilter(virNetServerClientPtr client,
virNetServerClientFilterFunc func,
void *opaque);
void virNetServerClientRemoveFilter(virNetServerClientPtr client,
int filterID);
int virNetServerClientGetAuth(virNetServerClientPtr client);
rpc: Introduce virNetServerSetClientAuthenticated Combine virNetServerClientSetAuth(client, VIR_NET_SERVER_SERVICE_AUTH_NONE) and virNetServerTrackCompletedAuth into one new function named virNetServerSetClientAuthenticated. After using this new function the function virNetServerTrackCompletedAuth was superfluous and is therefore removed. In addition, it is not very common that a '{{function}}' (virNetServerTrackCompletedAuth) does more than just the locking compared to '{{function}}Locked' (virNetServerTrackCompletedAuthLocked). virNetServerTrackPendingAuth was already superfluous and therefore it's also removed. Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: Stefan Zimmermann <stzi@linux.vnet.ibm.com> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-12-21 14:29:04 +00:00
void virNetServerClientSetAuthLocked(virNetServerClientPtr client, int auth);
Introduce generic RPC server objects To facilitate creation of new daemons providing XDR RPC services, pull a lot of the libvirtd daemon code into a set of reusable objects. * virNetServer: A server contains one or more services which accept incoming clients. It maintains the list of active clients. It has a list of RPC programs which can be used by clients. When clients produce a complete RPC message, the server passes this onto the corresponding program for handling, and queues any response back with the client. * virNetServerClient: Encapsulates a single client connection. All I/O for the client is handled, reading & writing RPC messages. * virNetServerProgram: Handles processing and dispatch of RPC method calls for a single RPC (program,version). Multiple programs can be registered with the server. * virNetServerService: Encapsulates socket(s) listening for new connections. Each service listens on a single host/port, but may have multiple sockets if on a dual IPv4/6 host. Each new daemon now merely has to define the list of RPC procedures & their handlers. It does not need to deal with any network related functionality at all.
2010-12-01 16:36:40 +00:00
bool virNetServerClientGetReadonly(virNetServerClientPtr client);
admin: Use the connection to determine a client is connected readonly Prior to this change, we relied solely on the inherited readonly attribute of a service's socket. This only worked for our UNIX sockets (and only to some degree), but doesn't work for TCP sockets which are RW by default, but such connections support RO as well. This patch forces an update on the client object once we have established a connection to reflect the nature of the connection itself rather than relying on the underlying socket's attributes. Clients connected to the admin server have always been connected as RW only. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1524399 Signed-off-by: Erik Skultety <eskultet@redhat.com>
2017-12-13 13:39:40 +00:00
void virNetServerClientSetReadonly(virNetServerClientPtr client, bool readonly);
rpc: virnetserverclient: Identify clients by an integer ID Admin API needs a way of addressing specific clients. Unlike servers, which we are happy to address by names both because its name reflects its purpose (to some extent) and we only have two of them (so far), naming clients doesn't make any sense, since a) each client is an anonymous, i.e. not recognized after a disconnect followed by a reconnect, b) we can't predict what kind of requests it's going to send to daemon, and c) the are loads of them comming and going, so the only viable option is to use an ID which is of a reasonably wide data type. Signed-off-by: Erik Skultety <eskultet@redhat.com>
2016-04-13 18:54:40 +00:00
unsigned long long virNetServerClientGetID(virNetServerClientPtr client);
rpc: virnetserverclient: Introduce new attribute conn_time to client Besides ID, libvirt should provide several parameters to help the user distinguish two clients from each other. One of them is the connection timestamp. This patch also adds a testcase for proper JSON formatting of the new attribute too (proper formatting of older clients that did not support this attribute yet is included in the existing tests) - in order to testGenerateJSON to work, a mock of time_t time(time_t *timer) needed to be created. Signed-off-by: Erik Skultety <eskultet@redhat.com>
2016-04-12 17:21:43 +00:00
long long virNetServerClientGetTimestamp(virNetServerClientPtr client);
Introduce generic RPC server objects To facilitate creation of new daemons providing XDR RPC services, pull a lot of the libvirtd daemon code into a set of reusable objects. * virNetServer: A server contains one or more services which accept incoming clients. It maintains the list of active clients. It has a list of RPC programs which can be used by clients. When clients produce a complete RPC message, the server passes this onto the corresponding program for handling, and queues any response back with the client. * virNetServerClient: Encapsulates a single client connection. All I/O for the client is handled, reading & writing RPC messages. * virNetServerProgram: Handles processing and dispatch of RPC method calls for a single RPC (program,version). Multiple programs can be registered with the server. * virNetServerService: Encapsulates socket(s) listening for new connections. Each service listens on a single host/port, but may have multiple sockets if on a dual IPv4/6 host. Each new daemon now merely has to define the list of RPC procedures & their handlers. It does not need to deal with any network related functionality at all.
2010-12-01 16:36:40 +00:00
bool virNetServerClientHasTLSSession(virNetServerClientPtr client);
Add APIs to get at more client security data 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>
2012-01-20 17:18:28 +00:00
virNetTLSSessionPtr virNetServerClientGetTLSSession(virNetServerClientPtr client);
Introduce generic RPC server objects To facilitate creation of new daemons providing XDR RPC services, pull a lot of the libvirtd daemon code into a set of reusable objects. * virNetServer: A server contains one or more services which accept incoming clients. It maintains the list of active clients. It has a list of RPC programs which can be used by clients. When clients produce a complete RPC message, the server passes this onto the corresponding program for handling, and queues any response back with the client. * virNetServerClient: Encapsulates a single client connection. All I/O for the client is handled, reading & writing RPC messages. * virNetServerProgram: Handles processing and dispatch of RPC method calls for a single RPC (program,version). Multiple programs can be registered with the server. * virNetServerService: Encapsulates socket(s) listening for new connections. Each service listens on a single host/port, but may have multiple sockets if on a dual IPv4/6 host. Each new daemon now merely has to define the list of RPC procedures & their handlers. It does not need to deal with any network related functionality at all.
2010-12-01 16:36:40 +00:00
int virNetServerClientGetTLSKeySize(virNetServerClientPtr client);
Convert HAVE_SASL to WITH_SASL Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-09-20 11:58:29 +00:00
# ifdef WITH_SASL
virneserverclient: Introduce virNetServerClientHasSASLSession We do have a similar method, serving the same purpose, for TLS, but we lack one for SASL. So introduce one, in order for other modules to be able to find out, if a SASL session is active, or better said, that a SASL session exists at all. Signed-off-by: Erik Skultety <eskultet@redhat.com>
2016-04-22 10:54:26 +00:00
bool virNetServerClientHasSASLSession(virNetServerClientPtr client);
Introduce generic RPC server objects To facilitate creation of new daemons providing XDR RPC services, pull a lot of the libvirtd daemon code into a set of reusable objects. * virNetServer: A server contains one or more services which accept incoming clients. It maintains the list of active clients. It has a list of RPC programs which can be used by clients. When clients produce a complete RPC message, the server passes this onto the corresponding program for handling, and queues any response back with the client. * virNetServerClient: Encapsulates a single client connection. All I/O for the client is handled, reading & writing RPC messages. * virNetServerProgram: Handles processing and dispatch of RPC method calls for a single RPC (program,version). Multiple programs can be registered with the server. * virNetServerService: Encapsulates socket(s) listening for new connections. Each service listens on a single host/port, but may have multiple sockets if on a dual IPv4/6 host. Each new daemon now merely has to define the list of RPC procedures & their handlers. It does not need to deal with any network related functionality at all.
2010-12-01 16:36:40 +00:00
void virNetServerClientSetSASLSession(virNetServerClientPtr client,
virNetSASLSessionPtr sasl);
Add APIs to get at more client security data 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>
2012-01-20 17:18:28 +00:00
virNetSASLSessionPtr virNetServerClientGetSASLSession(virNetServerClientPtr client);
Introduce generic RPC server objects To facilitate creation of new daemons providing XDR RPC services, pull a lot of the libvirtd daemon code into a set of reusable objects. * virNetServer: A server contains one or more services which accept incoming clients. It maintains the list of active clients. It has a list of RPC programs which can be used by clients. When clients produce a complete RPC message, the server passes this onto the corresponding program for handling, and queues any response back with the client. * virNetServerClient: Encapsulates a single client connection. All I/O for the client is handled, reading & writing RPC messages. * virNetServerProgram: Handles processing and dispatch of RPC method calls for a single RPC (program,version). Multiple programs can be registered with the server. * virNetServerService: Encapsulates socket(s) listening for new connections. Each service listens on a single host/port, but may have multiple sockets if on a dual IPv4/6 host. Each new daemon now merely has to define the list of RPC procedures & their handlers. It does not need to deal with any network related functionality at all.
2010-12-01 16:36:40 +00:00
# endif
int virNetServerClientGetFD(virNetServerClientPtr client);
bool virNetServerClientIsSecure(virNetServerClientPtr client);
Add APIs to get at more client security data 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>
2012-01-20 17:18:28 +00:00
bool virNetServerClientIsLocal(virNetServerClientPtr client);
Rename APIs for fetching UNIX socket credentials To avoid a namespace clash with forthcoming identity APIs, rename the virNet*GetLocalIdentity() APIs to have the form virNet*GetUNIXIdentity() * daemon/remote.c, src/libvirt_private.syms: Update for renamed APIs * src/rpc/virnetserverclient.c, src/rpc/virnetserverclient.h, src/rpc/virnetsocket.c, src/rpc/virnetsocket.h: s/LocalIdentity/UNIXIdentity/
2012-01-18 17:41:36 +00:00
int virNetServerClientGetUNIXIdentity(virNetServerClientPtr client,
Include process start time when doing polkit checks Since PIDs can be reused, polkit prefers to be given a (PID,start time) pair. If given a PID on its own, it will attempt to lookup the start time in /proc/pid/stat, though this is subject to races. It is safer if the client app resolves the PID start time itself, because as long as the app has the client socket open, the client PID won't be reused. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-04-25 16:05:00 +00:00
uid_t *uid, gid_t *gid, pid_t *pid,
unsigned long long *timestamp);
Introduce generic RPC server objects To facilitate creation of new daemons providing XDR RPC services, pull a lot of the libvirtd daemon code into a set of reusable objects. * virNetServer: A server contains one or more services which accept incoming clients. It maintains the list of active clients. It has a list of RPC programs which can be used by clients. When clients produce a complete RPC message, the server passes this onto the corresponding program for handling, and queues any response back with the client. * virNetServerClient: Encapsulates a single client connection. All I/O for the client is handled, reading & writing RPC messages. * virNetServerProgram: Handles processing and dispatch of RPC method calls for a single RPC (program,version). Multiple programs can be registered with the server. * virNetServerService: Encapsulates socket(s) listening for new connections. Each service listens on a single host/port, but may have multiple sockets if on a dual IPv4/6 host. Each new daemon now merely has to define the list of RPC procedures & their handlers. It does not need to deal with any network related functionality at all.
2010-12-01 16:36:40 +00:00
Rename "security context" to "selinux context" There are various methods named "virXXXXSecurityContext", which are specific to SELinux. Rename them all to "virXXXXSELinuxContext". They will still raise errors at runtime if SELinux is not compiled in Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-04-25 10:33:43 +00:00
int virNetServerClientGetSELinuxContext(virNetServerClientPtr client,
char **context);
Add APIs to get at more client security data 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>
2012-01-20 17:18:28 +00:00
Add ability to get a virIdentity from a virNetServerClientPtr Add APIs which allow creation of a virIdentity from the info associated with a virNetServerClientPtr instance. This is done based on the results of client authentication processes like TLS, x509, SASL, SO_PEERCRED Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-01-23 15:05:01 +00:00
virIdentityPtr virNetServerClientGetIdentity(virNetServerClientPtr client);
Introduce generic RPC server objects To facilitate creation of new daemons providing XDR RPC services, pull a lot of the libvirtd daemon code into a set of reusable objects. * virNetServer: A server contains one or more services which accept incoming clients. It maintains the list of active clients. It has a list of RPC programs which can be used by clients. When clients produce a complete RPC message, the server passes this onto the corresponding program for handling, and queues any response back with the client. * virNetServerClient: Encapsulates a single client connection. All I/O for the client is handled, reading & writing RPC messages. * virNetServerProgram: Handles processing and dispatch of RPC method calls for a single RPC (program,version). Multiple programs can be registered with the server. * virNetServerService: Encapsulates socket(s) listening for new connections. Each service listens on a single host/port, but may have multiple sockets if on a dual IPv4/6 host. Each new daemon now merely has to define the list of RPC procedures & their handlers. It does not need to deal with any network related functionality at all.
2010-12-01 16:36:40 +00:00
void *virNetServerClientGetPrivateData(virNetServerClientPtr client);
Ensure client streams are closed when marking a client for close Every active stream results in a reference being held on the virNetServerClientPtr object. This meant that if a client quit with any streams active, although all I/O was stopped the virNetServerClientPtr object would leak. This causes libvirtd to leak any file handles associated with open streams when a client quit To fix this, when we call virNetServerClientClose there is a callback invoked which lets the daemon release the streams and thus the extra references * daemon/remote.c: Add a hook to close all streams * daemon/stream.c, daemon/stream.h: Add API for releasing all streams * src/rpc/virnetserverclient.c, src/rpc/virnetserverclient.h: Allow registration of a hook to trigger when closing client
2011-08-14 22:44:45 +00:00
typedef void (*virNetServerClientCloseFunc)(virNetServerClientPtr client);
void virNetServerClientSetCloseHook(virNetServerClientPtr client,
virNetServerClientCloseFunc cf);
Introduce generic RPC server objects To facilitate creation of new daemons providing XDR RPC services, pull a lot of the libvirtd daemon code into a set of reusable objects. * virNetServer: A server contains one or more services which accept incoming clients. It maintains the list of active clients. It has a list of RPC programs which can be used by clients. When clients produce a complete RPC message, the server passes this onto the corresponding program for handling, and queues any response back with the client. * virNetServerClient: Encapsulates a single client connection. All I/O for the client is handled, reading & writing RPC messages. * virNetServerProgram: Handles processing and dispatch of RPC method calls for a single RPC (program,version). Multiple programs can be registered with the server. * virNetServerService: Encapsulates socket(s) listening for new connections. Each service listens on a single host/port, but may have multiple sockets if on a dual IPv4/6 host. Each new daemon now merely has to define the list of RPC procedures & their handlers. It does not need to deal with any network related functionality at all.
2010-12-01 16:36:40 +00:00
void virNetServerClientSetDispatcher(virNetServerClientPtr client,
virNetServerClientDispatchFunc func,
void *opaque);
void virNetServerClientClose(virNetServerClientPtr client);
rpc: Correct locking and simplify the function The lock for @client must not only be held for the duration of checking whether the client wants to close, but also for as long as we're closing the client. The same applies to the tracking of authentications. Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
2017-12-21 14:29:03 +00:00
void virNetServerClientCloseLocked(virNetServerClientPtr client);
bool virNetServerClientIsClosedLocked(virNetServerClientPtr client);
Fix sending of reply to final RPC message The dispatch for the CLOSE RPC call was invoking the method virNetServerClientClose(). This caused the client connection to be immediately terminated. This meant the reply to the final RPC message was never sent. Prior to the RPC rewrite we merely flagged the connection for closing, and actually closed it when the next RPC call dispatch had completed. * daemon/remote.c: Flag connection for a delayed close * daemon/stream.c: Update to use new API for closing failed connection * src/rpc/virnetserverclient.c, src/rpc/virnetserverclient.h: Add support for a delayed connection close. Rename the virNetServerClientMarkClose method to virNetServerClientImmediateClose to clarify its semantics
2011-07-08 11:54:29 +00:00
void virNetServerClientDelayedClose(virNetServerClientPtr client);
void virNetServerClientImmediateClose(virNetServerClientPtr client);
rpc: Correct locking and simplify the function The lock for @client must not only be held for the duration of checking whether the client wants to close, but also for as long as we're closing the client. The same applies to the tracking of authentications. Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
2017-12-21 14:29:03 +00:00
bool virNetServerClientWantCloseLocked(virNetServerClientPtr client);
Introduce generic RPC server objects To facilitate creation of new daemons providing XDR RPC services, pull a lot of the libvirtd daemon code into a set of reusable objects. * virNetServer: A server contains one or more services which accept incoming clients. It maintains the list of active clients. It has a list of RPC programs which can be used by clients. When clients produce a complete RPC message, the server passes this onto the corresponding program for handling, and queues any response back with the client. * virNetServerClient: Encapsulates a single client connection. All I/O for the client is handled, reading & writing RPC messages. * virNetServerProgram: Handles processing and dispatch of RPC method calls for a single RPC (program,version). Multiple programs can be registered with the server. * virNetServerService: Encapsulates socket(s) listening for new connections. Each service listens on a single host/port, but may have multiple sockets if on a dual IPv4/6 host. Each new daemon now merely has to define the list of RPC procedures & their handlers. It does not need to deal with any network related functionality at all.
2010-12-01 16:36:40 +00:00
int virNetServerClientInit(virNetServerClientPtr client);
Implement keepalive protocol in libvirt daemon
2011-08-24 13:33:34 +00:00
int virNetServerClientInitKeepAlive(virNetServerClientPtr client,
int interval,
unsigned int count);
bool virNetServerClientCheckKeepAlive(virNetServerClientPtr client,
virNetMessagePtr msg);
int virNetServerClientStartKeepAlive(virNetServerClientPtr client);
Rename virNetServerClient*AddrString Add SASL at the end to make the format obvious.
2016-06-20 14:04:49 +00:00
const char *virNetServerClientLocalAddrStringSASL(virNetServerClientPtr client);
const char *virNetServerClientRemoteAddrStringSASL(virNetServerClientPtr client);
Introduce virNetServerClientRemoteAddrStringURI Use it in virNetServerClientGetInfo to switch back to using the URI-format (separated by ':') instead of the SASL format (separated by ';'). Also use it in the error message reported by virNetServerAddClient.
2016-06-20 13:51:18 +00:00
const char *virNetServerClientRemoteAddrStringURI(virNetServerClientPtr client);
Introduce generic RPC server objects To facilitate creation of new daemons providing XDR RPC services, pull a lot of the libvirtd daemon code into a set of reusable objects. * virNetServer: A server contains one or more services which accept incoming clients. It maintains the list of active clients. It has a list of RPC programs which can be used by clients. When clients produce a complete RPC message, the server passes this onto the corresponding program for handling, and queues any response back with the client. * virNetServerClient: Encapsulates a single client connection. All I/O for the client is handled, reading & writing RPC messages. * virNetServerProgram: Handles processing and dispatch of RPC method calls for a single RPC (program,version). Multiple programs can be registered with the server. * virNetServerService: Encapsulates socket(s) listening for new connections. Each service listens on a single host/port, but may have multiple sockets if on a dual IPv4/6 host. Each new daemon now merely has to define the list of RPC procedures & their handlers. It does not need to deal with any network related functionality at all.
2010-12-01 16:36:40 +00:00
int virNetServerClientSendMessage(virNetServerClientPtr client,
virNetMessagePtr msg);
rpc: Replace virNetServerClientNeedAuth with virNetServerClientIsAuthenticated Replace virNetServerClientNeedAuth with virNetServerClientIsAuthenticated because it makes it clearer what it means. Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: Stefan Zimmermann <stzi@linux.vnet.ibm.com>
2017-12-21 14:29:08 +00:00
bool virNetServerClientIsAuthenticated(virNetServerClientPtr client);
rpc: virnetserver: Fix race on srv->nclients_unauth There is a race between virNetServerProcessClients (main thread) and remoteDispatchAuthList/remoteDispatchAuthPolkit/remoteSASLFinish (worker thread) that can lead to decrementing srv->nclients_unauth when it's zero. Since virNetServerCheckLimits relies on the value srv->nclients_unauth the underrun causes libvirtd to stop accepting new connections forever. Example race scenario (assuming libvirtd is using policykit and the client is privileged): 1. The client calls the RPC remoteDispatchAuthList => remoteDispatchAuthList is executed on a worker thread (Thread T1). We're assuming now the execution stops for some time before the line 'virNetServerClientSetAuth(client, 0)' 2. The client closes the connection irregularly. This causes the event loop to wake up and virNetServerProcessClient to be called (on the main thread T0). During the virNetServerProcessClients the srv lock is hold. The condition virNetServerClientNeedAuth(client) will be checked and as the authentication is not finished right now virNetServerTrackCompletedAuthLocked(srv) will be called => --srv->nclients_unauth => 0 3. The Thread T1 continues, marks the client as authenticated, and calls virNetServerTrackCompletedAuthLocked(srv) => --srv->nclients_unauth => --0 => wrap around as nclient_unauth is unsigned 4. virNetServerCheckLimits(srv) will disable the services forever To fix it, add an auth_pending field to the client struct so that it is now possible to determine if the authentication process has already been handled for this client. Setting the authentication method to none for the client in virNetServerProcessClients is not a proper way to indicate that the counter has been decremented, as this would imply that the client is authenticated. Additionally, adjust the existing test cases for this new field. Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
2017-12-21 14:29:05 +00:00
bool virNetServerClientIsAuthPendingLocked(virNetServerClientPtr client);
void virNetServerClientSetAuthPendingLocked(virNetServerClientPtr client, bool auth_pending);
Introduce generic RPC server objects To facilitate creation of new daemons providing XDR RPC services, pull a lot of the libvirtd daemon code into a set of reusable objects. * virNetServer: A server contains one or more services which accept incoming clients. It maintains the list of active clients. It has a list of RPC programs which can be used by clients. When clients produce a complete RPC message, the server passes this onto the corresponding program for handling, and queues any response back with the client. * virNetServerClient: Encapsulates a single client connection. All I/O for the client is handled, reading & writing RPC messages. * virNetServerProgram: Handles processing and dispatch of RPC method calls for a single RPC (program,version). Multiple programs can be registered with the server. * virNetServerService: Encapsulates socket(s) listening for new connections. Each service listens on a single host/port, but may have multiple sockets if on a dual IPv4/6 host. Each new daemon now merely has to define the list of RPC procedures & their handlers. It does not need to deal with any network related functionality at all.
2010-12-01 16:36:40 +00:00
rpc: virnetserverclient: Implement client connection transport retrieval Although we document 6 types of transport that we support, internally we can only differentiate between TCP, TLS, and UNIX transports only, since both SSH and libssh2 transports, due to using netcat, behave in the exactly the same way as a UNIX socket. Signed-off-by: Erik Skultety <eskultet@redhat.com>
2016-04-14 22:25:04 +00:00
int virNetServerClientGetTransport(virNetServerClientPtr client);
virnetserverclient: Add an internal method to retrieve client's identity This method just aggregates various client object attributes, like socket address, connection type (RO/RW), and some TCP/TLS/UNIX identity in an atomic manner. Signed-off-by: Erik Skultety <eskultet@redhat.com>
2016-04-22 11:08:10 +00:00
int virNetServerClientGetInfo(virNetServerClientPtr client,
Fix possible invalid read in adminClientGetInfo virNetServerClientGetInfo returns the client's remote address as a string, which is a part of the client object. Use VIR_STRDUP to make a copy which can be freely accessed even after the virNetServerClient object is unlocked. To reproduce, put a sleep between virObjectUnlock in virNetServerClientGetInfo and virTypedParamsAddString in adminClientGetInfo, then close the queried connection during that sleep.
2016-06-29 05:03:13 +00:00
bool *readonly, char **sock_addr,
virnetserverclient: Add an internal method to retrieve client's identity This method just aggregates various client object attributes, like socket address, connection type (RO/RW), and some TCP/TLS/UNIX identity in an atomic manner. Signed-off-by: Erik Skultety <eskultet@redhat.com>
2016-04-22 11:08:10 +00:00
virIdentityPtr *identity);
Introduce generic RPC server objects To facilitate creation of new daemons providing XDR RPC services, pull a lot of the libvirtd daemon code into a set of reusable objects. * virNetServer: A server contains one or more services which accept incoming clients. It maintains the list of active clients. It has a list of RPC programs which can be used by clients. When clients produce a complete RPC message, the server passes this onto the corresponding program for handling, and queues any response back with the client. * virNetServerClient: Encapsulates a single client connection. All I/O for the client is handled, reading & writing RPC messages. * virNetServerProgram: Handles processing and dispatch of RPC method calls for a single RPC (program,version). Multiple programs can be registered with the server. * virNetServerService: Encapsulates socket(s) listening for new connections. Each service listens on a single host/port, but may have multiple sockets if on a dual IPv4/6 host. Each new daemon now merely has to define the list of RPC procedures & their handlers. It does not need to deal with any network related functionality at all.
2010-12-01 16:36:40 +00:00
rpc: serverclient: Add option to suppress errors on EOF The protocol may not use an explicit API to close the connection and just close the socket instead. Add option to suppress errors in such case.
2017-03-17 15:18:08 +00:00
void virNetServerClientSetQuietEOF(virNetServerClientPtr client);
Introduce generic RPC server objects To facilitate creation of new daemons providing XDR RPC services, pull a lot of the libvirtd daemon code into a set of reusable objects. * virNetServer: A server contains one or more services which accept incoming clients. It maintains the list of active clients. It has a list of RPC programs which can be used by clients. When clients produce a complete RPC message, the server passes this onto the corresponding program for handling, and queues any response back with the client. * virNetServerClient: Encapsulates a single client connection. All I/O for the client is handled, reading & writing RPC messages. * virNetServerProgram: Handles processing and dispatch of RPC method calls for a single RPC (program,version). Multiple programs can be registered with the server. * virNetServerService: Encapsulates socket(s) listening for new connections. Each service listens on a single host/port, but may have multiple sockets if on a dual IPv4/6 host. Each new daemon now merely has to define the list of RPC procedures & their handlers. It does not need to deal with any network related functionality at all.
2010-12-01 16:36:40 +00:00
#endif /* __VIR_NET_SERVER_CLIENT_H__ */
Reference in New Issue Copy Permalink