[SAMBA4] Loosing information in the socket system

[Andrew Bartlett]

On Sun, 2006-01-01 at 18:57 +0100, Stefan (metze) Metzmacher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Andrew Bartlett schrieb:
> > I've been looking at the reasons why Samba4's kpasswd is incompatible
> > with Heimdal clients, and I think the issue is related to IP addresses
> > embedded in the kerberos messages (to prevent replay/forgery).
> > 
> > What bothers me is that as a result of the BSD socket functions, we get
> > the struct sockaddr that I need to pass into the kerberos libraries.
> > Unfortunately, we instead go via text, as you can see in
> > kdc/kdc.c:kdc_process.c
> > 
> > 	/* TODO:  This really should be in a utility function somewhere */
> > 	ZERO_STRUCT(src_sock_addr);
> > #ifdef HAVE_SOCK_SIN_LEN
> > 	src_sock_addr.sin_len		= sizeof(src_sock_addr);
> > #endif
> > 	addr				= interpret_addr2(src_addr);
> > 	src_sock_addr.sin_addr.s_addr	= addr.addr;
> > 	src_sock_addr.sin_port		= htons(src_port);
> > 	src_sock_addr.sin_family	= PF_INET;
> 
> I think generic functions that create a struct sockaddr from a string
> should be the way to go, but I'll look at that the next days more closely.

To do that right, wouldn't we need to pass the socket type around as
well?

That set me of thinking:  I understand partly why we moved to strings in
the first place, but what about a structure:

struct socket_address {
	char *type;
	struct sockaddr *sockaddr;
	char *address;
	int port;
}

This would be the arguments to all the socket functions such as
recvfrom(), sendto(), getpeername() and getsockname().  When being
returned, if struct sockaddr makes sense for this particular socket
type, it would return the sockaddr.  If not, then it would be NULL.  

For 'set' functions if no sockaddr is from the caller available (say on
a connect), then the socket layer should do the above interpret_addr2()
and the like.  (This avoids the rest of the code dealing with sockaddr
as anything more than an opaque quantity, which is why we ended up with
text at the moment).

This would avoid passing around two separate parameters, be easy to fit
into existing code, yet never pull apart the sockaddr between a recvfrom
and sendto call.  

Comments?

> > Index: lib/socket/config.m4
> > ===================================================================
> > --- lib/socket/config.m4	(revision 12651)
> > +++ lib/socket/config.m4	(working copy)
> > @@ -18,9 +18,9 @@
> >  # it.
> >  AC_CHECK_FUNCS(connect)
> >  if test x"$ac_cv_func_connect" = x"no"; then
> > -    AC_CHECK_LIB(nsl_s, printf)
> > -    AC_CHECK_LIB(nsl, printf)
> > -    AC_CHECK_LIB(socket, connect)
> > +    AC_CHECK_LIB_EXT(nsl_s, printf)
> > +    AC_CHECK_LIB_EXT(nsl, printf)
> > +    AC_CHECK_LIB_EXT(socket, connect)
> >      AC_CHECK_LIB_EXT(inet, connect)
> 
> didn't the AC_CHECK_LIB_EXT needs 3 parameters? I think there's
> something wrong in the current version, I'll look at this too.

This came up out of bug 3365.

> > +NTSTATUS socket_get_my_sock_addr(struct socket_context *sock, struct sockaddr *my_addr);
> > +NTSTATUS socket_get_peer_sock_addr(struct socket_context *sock, struct sockaddr *peer_addr);
> >  NTSTATUS socket_dup(struct socket_context *sock);
> 
> I don't like that...

Neither do I, as I realised I would need recvfrom, sendto duplicated as
well.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20060102/29b9bf7c/attachment.bin