Return to ci_security.h CVS log

Up to [Development] / failsafe / FailSafe / cluster_services / include

Initial checkin

/*
 * Copyright (c) 2000 Silicon Graphics, Inc.  All Rights Reserved.
 * 
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of version 2 of the GNU General Public License as
 * published by the Free Software Foundation.
 * 
 * This program is distributed in the hope that it would be useful, but
 * WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 * 
 * Further, this software is distributed without any warranty that it is
 * free of the rightful claim of any third person regarding infringement
 * or the like.  Any license provided herein, whether implied or
 * otherwise, applies only to this software file.  Patent licenses, if
 * any, provided herein do not apply to combinations of this program with
 * other software, or any other product whatsoever.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write the Free Software Foundation,
 * Inc., 59 Temple Place - Suite 330, Boston MA 02111-1307, USA.
 * 
 * Contact information: Silicon Graphics, Inc., 1600 Amphitheatre Pkwy,
 * Mountain View, CA 94043, or:
 * 
 * http://www.sgi.com 
 * 
 * For further information regarding this notice, see: 
 * 
 * http://oss.sgi.com/projects/GenInfo/NoticeExplan
 */
/*
 * ci_security.h
 *
 * This file contains data structure definitions and function
 * prototypes associated with enforcing security in a CHAOS
 * cluster beyond what is provided by message authentication
 * and encryption. 
 *
 * We will add more checks to the functions as we think of
 * other scenarios, but for now, the following two types of
 * "security" issues are dealt with.
 * (i) A node in a cluster receives a message from a node
 *     which is part of another cluster (possibly due to
 *     some misconfiguartion).
 *     Solution: Every time a msg is sent out, the local
 *               cluster id (which is a unique number) is
 *               sent along with the msg. The receiver accepts
 *               the data ONLY if the cluster ids match.
 * (ii)A node in a cluster receives a message from an ip addr
 *     that it does not know about as a "control" network.
 *     Solution: Every time a msg is sent out, the local node
 *               id is sent along. The receiver compares the
 *               remote address (obtained as a byproduct
 *		 of the client doing recvfrom etc) with the
 *               corresponding part (keyed off by nodeid(
 *               in its configuration information.
 * 
 * Any CHAOS daemon wishing to utilize the above functionality
 * must contain the struct ci_security_elems_t in its msg structure;
 * and pass a pointer to that to the two corresp check functions. 
 * This structure stores the two fields clusterid and source nodeid
 * mentioned above.
 *
 * The function ci_security_sendmsg_validate() should be called by a
 * daemon BEFORE it calls the authentication/encryption fns prior
 * to sending a message. This will add the two fields of the struct
 * ci_security_elems_t to an outgoing message.
 *
 * The function ci_security_recvmsg_validate() should be called by 
 * a deamon AFTER it calls the de-authentication/de-encryption fns
 * on receiving a message. This fn will do the above two checks.
 * 
 * For the ipaddr check, the daemon needs to provide a pointer to
 * a list of (node, iplist) pairs, as defined in the structures below.
 * This list can either be constructed by the daemon if it already
 * has read it from the (CDB) configuration as part of its own
 * other requirements, or the daemon/client can request this code
 * to construct this list for it. It can indicate this need by
 * passing a B_TRUE as the second argument to the function
 * ci_security_init(). Every subsequent reinitialization call
 * (in response to changes in the CDB) will result in this ipaddr
 * list being reformed by this code.
 * This implies that it must register to be notified of changes
 * in the #global#machines subtree (since the IP addresses reside
 * under #global#machines#hostx#NetworkInterface subtree).
 * This case is useful for daemons that do not otherwise need to 
 * read the ip address information directly (ex. GCD).
 * Also, a client must specify whether or not they would like to
 * communicate on the control network or not - 3rd arg to the
 * ci_security_init() function.
 *
 */

#ifndef CI_SECURITY_H
#define CI_SECURITY_H
#ident "$Id: ci_security.h,v 1.1 2000/08/31 19:16:32 vasa Exp $"

#include <netinet/in.h>

typedef struct ci_security_elems_s {
    ci_clusterid_t	sender_clusterid;
    ci_nodeid_t		sender_nodeid;
} ci_security_elems_t;

typedef struct ci_security_ipaddr_s {
    ci_nodeid_t			nodeid;
    ci_nlist_t			*ipaddrs;  
				/* Elements of type struct sockaddr_in *. */
} ci_security_ipaddr_t;
 
typedef struct ci_security_iplist_s {
    ci_nlist_t			*node_iplist; 
				/* Elements of type ci_security_ipaddr_t *. */
} ci_security_iplist_t;


/* Prototypes from lib/libci/src/misc/ci_security.c. */
ci_err_t		ci_security_init(ci_nodeid_t, 
					 boolean_t, 
					 boolean_t,
					 boolean_t);
ci_err_t		ci_security_reinit(ci_nodeid_t);
ci_err_t		ci_security_sendmsg_validate(ci_security_elems_t *);
ci_err_t		ci_security_recvmsg_validate(struct sockaddr_in *,
						     ci_security_elems_t *,
						     ci_security_iplist_t *);

/* Prototypes from lib/libci/src/misc/ci_security_lists.c. */
ci_security_iplist_t	*ci_security_iplist_create(void);
void			ci_security_iplist_cleanup(ci_security_iplist_t *);
ci_security_ipaddr_t	*ci_security_ipaddr_create(ci_security_iplist_t *);

#endif /* CI_SECURITY_H */