net/memif: fix invalid unix domain address length

  Define MEMIF_SOCKET_UN_SIZE to size of unix domain socket address.
Report error in case of longer path.

Fixes: b923866c6974 ("net/memif: allow for full key size in socket name")
Cc: stephen@networkplumber.org

Signed-off-by: Jakub Grajciar <jgrajcia@cisco.com>
---
 doc/guides/nics/memif.rst         |  2 +-
 drivers/net/memif/memif_socket.c  | 27 +++++++++++----------------
 drivers/net/memif/memif_socket.h  |  6 ++++--
 drivers/net/memif/rte_eth_memif.c |  5 +++++
 4 files changed, 21 insertions(+), 19 deletions(-)
  

On 10/22/2019 5:08 PM, Jakub Grajciar wrote:
> Define MEMIF_SOCKET_UN_SIZE to size of unix domain socket address.
> Report error in case of longer path.
> 
> Fixes: b923866c6974 ("net/memif: allow for full key size in socket name")
> Cc: stephen@networkplumber.org
> 
> Signed-off-by: Jakub Grajciar <jgrajcia@cisco.com>

<...>

> +  if (strlen(filename) != MEMIF_SOCKET_UN_SIZE) {
> +		MIF_LOG(ERR, "Unix socket address too long (max 108).");
> +		return -1;
> +	}

Are you sure about this check, I didn't test it but intention looks like ">=".

btw, it is possible to print 'MEMIF_SOCKET_UN_SIZE' as max value, instead of
hardcoded '108'.
  

> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Tuesday, October 22, 2019 6:33 PM
> To: Jakub Grajciar -X (jgrajcia - PANTHEON TECHNOLOGIES at Cisco)
> <jgrajcia@cisco.com>; dev@dpdk.org
> Cc: stephen@networkplumber.org
> Subject: Re: [dpdk-dev] [PATCH] net/memif: fix invalid unix domain address
> length
> 
> On 10/22/2019 5:08 PM, Jakub Grajciar wrote:
> > Define MEMIF_SOCKET_UN_SIZE to size of unix domain socket address.
> > Report error in case of longer path.
> >
> > Fixes: b923866c6974 ("net/memif: allow for full key size in socket
> > name")
> > Cc: stephen@networkplumber.org
> >
> > Signed-off-by: Jakub Grajciar <jgrajcia@cisco.com>
> 
> <...>
> 
> > +  if (strlen(filename) != MEMIF_SOCKET_UN_SIZE) {
> > +		MIF_LOG(ERR, "Unix socket address too long (max 108).");
> > +		return -1;
> > +	}
> 
> Are you sure about this check, I didn't test it but intention looks like ">=".

Thanks, I'll fix that in next version.

> 
> btw, it is possible to print 'MEMIF_SOCKET_UN_SIZE' as max value, instead of
> hardcoded '108'.
  

On Tue, 22 Oct 2019 18:08:29 +0200
Jakub Grajciar <jgrajcia@cisco.com> wrote:

> Cc: stephen@networkplumber.org
> 
> Signed-off-by: Jakub Grajciar <jgrajcia@cisco.com>
> ---
>  doc/guides/nics/memif.rst         |  2 +-
>  drivers/net/memif/memif_socket.c  | 27 +++++++++++----------------
>  drivers/net/memif/memif_socket.h  |  6 ++++--
>  drivers/net/memif/rte_eth_memif.c |  5 +++++
>  4 files changed, 21 insertions(+), 19 deletions(-)
> 
> diff --git a/doc/guides/nics/memif.rst b/doc/guides/nics/memif.rst
> index de2d481eb..9a568455e 100644
> --- a/doc/guides/nics/memif.rst
> +++ b/doc/guides/nics/memif.rst
> @@ -42,7 +42,7 @@ client.
>     "role=master", "Set memif role", "slave", "master|slave"
>     "bsize=1024", "Size of single packet buffer", "2048", "uint16_t"
>     "rsize=11", "Log2 of ring size. If rsize is 10, actual ring size is 1024", "10", "1-14"
> -   "socket=/tmp/memif.sock", "Socket filename", "/tmp/memif.sock", "string len 256"
> +   "socket=/tmp/memif.sock", "Socket filename", "/tmp/memif.sock", "string len 108"
>     "mac=01:23:45:ab:cd:ef", "Mac address", "01:ab:23:cd:45:ef", ""
>     "secret=abc123", "Secret is an optional security option, which if specified, must be matched by peer", "", "string len 24"
>     "zero-copy=yes", "Enable/disable zero-copy slave mode", "no", "yes|no"
> diff --git a/drivers/net/memif/memif_socket.c b/drivers/net/memif/memif_socket.c
> index 0c71f6c45..4efa68e1a 100644
> --- a/drivers/net/memif/memif_socket.c
> +++ b/drivers/net/memif/memif_socket.c
> @@ -7,7 +7,6 @@
>  #include <unistd.h>
>  #include <sys/types.h>
>  #include <sys/socket.h>
> -#include <sys/un.h>
>  #include <sys/ioctl.h>
>  #include <errno.h>
>  
> @@ -860,16 +859,12 @@ memif_listener_handler(void *arg)
>  		rte_free(cc);
>  }
>  
> -#define MEMIF_SOCKET_UN_SIZE	\
> -	(offsetof(struct sockaddr_un, sun_path) + MEMIF_SOCKET_KEY_LEN)
> -
>  static struct memif_socket *
>  memif_socket_create(struct pmd_internals *pmd,
>  		    const char *key, uint8_t listener)
>  {
>  	struct memif_socket *sock;
> -	struct sockaddr_un *un;
> -	char un_buf[MEMIF_SOCKET_UN_SIZE];
> +	struct sockaddr_un un;
>  	int sockfd;
>  	int ret;
>  	int on = 1;
> @@ -881,7 +876,7 @@ memif_socket_create(struct pmd_internals *pmd,
>  	}
>  
>  	sock->listener = listener;
> -	strlcpy(sock->filename, key, MEMIF_SOCKET_KEY_LEN);
> +	strlcpy(sock->filename, key, MEMIF_SOCKET_UN_SIZE);
>  	TAILQ_INIT(&sock->dev_queue);
>  
>  	if (listener != 0) {
> @@ -889,18 +884,18 @@ memif_socket_create(struct pmd_internals *pmd,
>  		if (sockfd < 0)
>  			goto error;
>  
> -		memset(un_buf, 0, sizeof(un_buf));
> -		un = (struct sockaddr_un *)un_buf;
> -		un->sun_family = AF_UNIX;
> -		strlcpy(un->sun_path, sock->filename, MEMIF_SOCKET_KEY_LEN);
> +		un.sun_family = AF_UNIX;
> +		strlcpy(un.sun_path, sock->filename, MEMIF_SOCKET_UN_SIZE);


Why does this not use abstract unix domain socket naming?
That would be much less error prone, because then the socket would disappear
when all applications using it are closed.
  

> Why does this not use abstract unix domain socket naming?
> That would be much less error prone, because then the socket would
> disappear when all applications using it are closed.

How would that work with containers? I'll consider that for a new patch, maybe it could be optional?
  

On Tue, 22 Oct 2019 16:50:40 +0000
"Jakub Grajciar -X (jgrajcia - PANTHEON TECHNOLOGIES at Cisco)" <jgrajcia@cisco.com> wrote:

> > Why does this not use abstract unix domain socket naming?
> > That would be much less error prone, because then the socket would
> > disappear when all applications using it are closed.  
> 
> How would that work with containers? I'll consider that for a new patch, maybe it could be optional?
> 

Not sure, if they interact with fs namespaces (remember there really is no such
thing as containers). From unix(7)

   Abstract sockets
       Socket permissions have no meaning for abstract  sockets:  the  process
       umask(2)  has  no  effect when binding an abstract socket, and changing
       the ownership and permissions of the object  (via  fchown(2)  and  fch‐
       mod(2)) has no effect on the accessibility of the socket.

       Abstract  sockets  automatically  disappear when all open references to
       the socket are closed.

       The abstract socket namespace is a nonportable Linux extension.

Also pathname length restrictions are only because of the sizeof default sockaddr_un struct.
Kernel will accept bigger lengths if passed a bigger sockaddr.