Subject: Passing credentials as ancillary data
To: None <tech-kern@NetBSD.ORG>
From: Jason Thorpe <thorpej@nas.nasa.gov>
List: tech-kern
Date: 01/06/1998 23:09:19
Hi folks,

For any of you who have Stevens' _UNIX Network Programming, Vol 1. 2nd Ed._,
on page 390 is a description of an interface present in BSD/OS that allows
a recvmsg() to receive credentials from the sender.  These credentials
are in the form of a "struct fcred", which includes:

	- real uid
	- real gid
	- login name as set with setlogin(2)
	- a struct ucred (fields are renamed to look as if it's all
	  a single fcred structure)

The semantics are as follows:

	- For credentials to be sent, the receiver must have set the
	  LOCAL_CREDS socket option.  They are delivered as ancillary
	  data with level SOL_SOCKET and type SCM_CREDS.
	- If the socket is of type SOCK_DGRAM, credentials are delivered
	  with every datagram.
	- If the socket is of type SOCK_STREAM, credentials are delivered
	  only the first time data is sent (since the socket is effectively
	  connected).
	- If the sender attempts to forge a credential, the kernel will
	  discard it.

Additionally:
	- In the BSD/OS implementation, credentials cannot be passed
	  with file descriptors.  I consider this a bug, and will make
	  it possible to send both in my implementation.

Now, the one icky thing here is that it uses a struct ucred; this is
an internal kernel data structure, which really doesn't belong exported
out to userland.

Now, the ONLY reason I'm inclined to go with the interface is because
it's the one BSDI uses.  However, it would be fine with me to change
the structure of the message so that it's not dependent on the layout
of an internal kernel data structure.  I would actually be much happier
to use a structure like:

struct sockcred {
	uid_t	sc_uid;			/* real user id */
	uid_t	sc_euid;		/* effective user id */
	gid_t	sc_gid;			/* real group id */
	gid_t	sc_egid;		/* effective group id */
};

Really all you need are real and effective user/group ids (that's all
the rest of userland really has to play with, anyhow).

Comments?

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-6                                       Work: +1 650 604 0935
Moffett Field, CA 94035                             Pager: +1 415 428 6939