test: pipe_overlong_path fails on AIX

[abmusse]

• Version: Current v1.x branch
• Platform: AIX

Discovered this failure while running the CI for a pull request:

Ref: #4229

https://ci.nodejs.org/job/libuv-test-commit-aix/nodes=aix72-ppc64/2279/console

not ok 199 - pipe_overlong_path
# exit code 393222
# Output from process `pipe_overlong_path`:
# Assertion failed in test/test-pipe-bind-error.c on line 175: `UV_EINVAL == uv_pipe_bind2(&pipe, path, sizeof(path), UV_PIPE_NO_TRUNCATE)` (-22 == -86)

libuv/test/test-pipe-bind-error.c

Line 175 in 6be130e

ASSERT_EQ(UV_EINVAL,

Looks like errno 86 maps to ENAMETOOLONG on AIX.

Looks like this passes as expected on IBM i:

ok 199 - pipe_overlong_path

https://ci.nodejs.org/job/libuv-test-commit-aix/nodes=aix72-ppc64/2279/console

[bnoordhuis]

What is the size of struct sockaddr_un.sun_path on AIX?

[abmusse]

@bnoordhuis

What is the size of struct sockaddr_un.sun_path on AIX?

Looks like its set to 1024 or 1023

From: /usr/include/sys/un.h

#if defined(COMPAT_43) && !defined(_KERNEL)
struct  sockaddr_un {
        ushort_t        sun_family;     /* AF_UNIX */
        char        sun_path[1024]; /* changed from 104 to PATH_MAX to support long user names. This value should be ch
anged manually if PATH_MAX changes in future */
};
#else
struct  sockaddr_un {
        uchar_t     sun_len;            /* sockaddr len including null */
        sa_family_t sun_family;         /* AF_UNIX */
        char        sun_path[1023]; /* changed from 104 to PATH_MAX to support long user names. This value should be ch
anged manually if PATH_MAX changes in future */
};
#endif /* COMPAT_43 && !_KERNEL */

[abmusse]

@bnoordhuis @richardlau

I got around to adding some debug print statements to get a better understanding of what is going on. My changes are here for ref: https://github.com/libuv/libuv/compare/v1.x...abmusse:libuv:debug-pipe-overlong-path?expand=1

not ok 200 - pipe_overlong_path
# exit code 393222
# Output from process `pipe_overlong_path`:
# Calling uv_pipe_init
# 
# Calling uv_pipe_bind2
# 
# flags & UV_PIPE_NO_TRUNCATE
# 
# namelen: 512
# 
# saddr.sun_path: 1023
# 
# malloc pipe_fname
# 
# failed to bind sockfs
# 
# goto err_socket
# 
# In err_socket, err: -86
# 

ref: https://ci.nodejs.org/job/libuv-test-commit-aix/nodes=aix72-ppc64/lastBuild/console

I confirmed that saddr.sun_path is set to 1023.

The namelen being passed in test case is 512 which is why its skipping the check

libuv/src/unix/pipe.c

Lines 84 to 86 in 6be130e

	if (flags & UV_PIPE_NO_TRUNCATE)
	if (namelen > sizeof(saddr.sun_path))
	return UV_EINVAL;

The weird part is that bind fails when setting saddr.sun_path to the long name.

libuv/src/unix/pipe.c

Lines 116 to 127 in 6be130e

	memset(&saddr, 0, sizeof saddr);
	memcpy(&saddr.sun_path, name, namelen);
	saddr.sun_family = AF_UNIX;
	if (bind(sockfd, (struct sockaddr*)&saddr, sizeof saddr)) {
	err = UV__ERR(errno);
	/* Convert ENOENT to EACCES for compatibility with Windows. */
	if (err == UV_ENOENT)
	err = UV_EACCES;
	uv__close(sockfd);
	goto err_socket;

We get back errno 86 which looks like it maps to ENAMETOOLONG on AIX.

From my previous comment:

#if defined(COMPAT_43) && !defined(_KERNEL)
struct  sockaddr_un {
        ushort_t        sun_family;     /* AF_UNIX */
        char        sun_path[1024]; /* changed from 104 to PATH_MAX to support long user names. This value should be ch
anged manually if PATH_MAX changes in future */
};
#else
struct  sockaddr_un {
        uchar_t     sun_len;            /* sockaddr len including null */
        sa_family_t sun_family;         /* AF_UNIX */
        char        sun_path[1023]; /* changed from 104 to PATH_MAX to support long user names. This value should be ch
anged manually if PATH_MAX changes in future */
};
#endif /* COMPAT_43 && !_KERNEL */

It seems like on AIX sun_path was increased from support for long user names?

I think we need to find the true max allowed name length for a socket since the current sun_path of 1023 looks too big.

[abmusse]

As a follow up I made a re-producible program in C

// unix-sock.c
// gcc -o unix-sock unix-sock.c && ./unix-sock

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>
#include <sys/un.h>

int main() {
    int sockfd;
    struct sockaddr_un addr;
    size_t SIZE = sizeof(addr.sun_path);
    printf( "saddr.sun_path: %lu\n\n", SIZE);

    // Create a Unix domain socket
    sockfd = socket(AF_UNIX, SOCK_STREAM, 0);
    if (sockfd == -1) {
        perror("socket");
        exit(EXIT_FAILURE);
    }

    // Clear the structure
    memset(&addr, 0, sizeof(struct sockaddr_un));

    // Assign the socket family and the socket path
    addr.sun_family = AF_UNIX;
    printf( "setting sun_path to: %d @ chars\n\n", SIZE);
    memset(addr.sun_path, '@', SIZE);

    // Bind the socket
    if (bind(sockfd, (struct sockaddr *)&addr, sizeof(struct sockaddr_un)) == -1) {
        perror("bind");
        close(sockfd);
        exit(EXIT_FAILURE);
    }

    printf("Success!\n");
    close(sockfd);

    return 0;
}

I then compiled and ran it on AIX:

$ gcc -o unix-sock unix-sock.c && ./unix-sock
saddr.sun_path: 1023

setting sun_path to: 1023 @ chars

bind: File name too long

[abmusse]

CC

@richardlau
@bnoordhuis

I did some trial and error to figure out what is max possible name size and
it looks like the answer to that is 255.

It seems like AIX is using the NAME_MAX to determine what the max file name can
be rather than the saddr.sun_path size.

$ getconf NAME_MAX /
255
$ getconf PATH_MAX /
1024

As a side note, the NAME_MAX and PATH_MAX can be returned using pathconf

// gcc -o name-max name-max.c && ./name-max
#include <stdio.h>
#include <unistd.h>

int main(){

  long MAX_NAME_SIZE = pathconf(".", _PC_NAME_MAX);
  printf( "_PC_NAME_MAX: %ld\n\n", MAX_NAME_SIZE);

  long MAX_PATH_SIZE = pathconf(".", _PC_PATH_MAX);
  printf( "_PC_PATH_MAX: %ld\n\n", MAX_PATH_SIZE);

  return 0;
}

$ gcc -o name-max name-max.c && ./name-max
_PC_NAME_MAX: 255

_PC_PATH_MAX: 1024

So I re-ran the test program in with using the NAME_MAX value (255) and the
creation was successful. There is a file with name made up of 255 @ chars

$ gcc -o unix-sock unix-sock.c && ./unix-sock
saddr.sun_path: 1023

setting sun_path to: 255 @ chars

Success!
$ ls \@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@ 
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

So yes looks like we are capped by the NAME_MAX in the test case because we
are not setting a path at all just a file with a name of 512 bytes which is
larger than the 255 NAME_MAX therefore causing the error.

[richardlau]

It looks like ENAMETOOLONG is not unexpected then, based on the value of NAME_MAX?
ENAMETOOLONG is listed as an error in the POSIX documentation for bind (so this is not AIX specific behaviour):
https://pubs.opengroup.org/onlinepubs/9699919799/functions/bind.html

If the address family of the socket is AF_UNIX, then bind() shall fail if:
...
[ENAMETOOLONG]
The length of a component of a pathname is longer than {NAME_MAX}.

[abmusse]

@richardlau

It looks like ENAMETOOLONG is not unexpected then, based on the value of NAME_MAX?

Correct ENAMETOOLONG would be expected based on the value of NAME_MAX

Thanks for the info. Perhaps we should just allow the test case to accept ENAMETOOLONG as a valid expected error on AIX. That would be the simplest fix IMO.

[richardlau]

It seems like AIX is using the NAME_MAX to determine what the max file name can be rather than the saddr.sun_path size.

$ getconf NAME_MAX /
255
$ getconf PATH_MAX /
1024

Rereading https://pubs.opengroup.org/onlinepubs/9699919799/functions/bind.html I'm actually now wondering if POSIX allows PATH_MAX length paths in saddr.sun_path BUT individual components of the path can only be NAME_MAX long.

[ENAMETOOLONG]
The length of a component of a pathname is longer than {NAME_MAX}.
...
[ENAMETOOLONG]
The length of a pathname exceeds {PATH_MAX}, or pathname resolution of a symbolic link produced an intermediate result with a length that exceeds {PATH_MAX}.

and that on most other platforms sizeof(saddr.sun_path) is less than NAME_MAX?

Could we confirm what happen on AIX if a path is used such that individual components of the path (i.e. between path separators (/)) is within NAME_MAX?

[abmusse]

Rereading https://pubs.opengroup.org/onlinepubs/9699919799/functions/bind.html I'm actually now wondering if POSIX allows PATH_MAX length paths in saddr.sun_path BUT individual components of the path can only be NAME_MAX long.

I agree I think this is the case as well. individual components of the path can only be NAME_MAX long but the overall path length can be up to PATH_MAX.

I adjusted my code example to now set path of

./bind-test/@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

// unix-sock.c
// gcc -o unix-sock unix-sock.c && ./unix-sock

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>
#include <sys/un.h>

int main() {
    int sockfd;
    struct sockaddr_un addr;
    size_t SIZE = 255;
    printf( "saddr.sun_path: %lu\n\n", sizeof(addr.sun_path));

    // Create a Unix domain socket
    sockfd = socket(AF_UNIX, SOCK_STREAM, 0);
    if (sockfd == -1) {
        perror("socket");
        exit(EXIT_FAILURE);
    }

    // Clear the structure
    memset(&addr, 0, sizeof(struct sockaddr_un));

    // Assign the socket family and the socket path
    addr.sun_family = AF_UNIX;
    const char* long_path = "./bind-test/@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@";
    printf( "setting sun_path to: %d @ chars\n\n", strlen(long_path));
    strcpy(addr.sun_path, long_path);

    // Bind the socket
    if (bind(sockfd, (struct sockaddr *)&addr, sizeof(struct sockaddr_un)) == -1) {
        perror("bind");
        close(sockfd);
        exit(EXIT_FAILURE);
    }

    printf("Success!\n");
    close(sockfd);

    return 0;
}

$ gcc -o unix-sock unix-sock.c && ./unix-sock
saddr.sun_path: 1023

setting sun_path to: 267 @ chars

bind: No such file or directory

First pass fails because I need to create the bind-test dir first.

$ mkdir bind-test
$ gcc -o unix-sock unix-sock.c && ./unix-sock
saddr.sun_path: 1023

setting sun_path to: 267 @ chars

Success!
$ ls bind-test/
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Second run passed we were able to set the sun_path past the NAME_MAX of 255 -> 267.

and that on most other platforms sizeof(saddr.sun_path) is less than NAME_MAX?

Yes I think that is the case! I wrote a simple test program and ran it on Fedora Linux here was my results:

#include <stdio.h>
#include <unistd.h>
#include <sys/un.h>

int main(){
  struct sockaddr_un addr;
  printf( "saddr.sun_path: %lu\n\n", sizeof(addr.sun_path));

  long MAX_NAME_SIZE = pathconf(".", _PC_NAME_MAX);
  printf( "_PC_NAME_MAX: %ld\n\n", MAX_NAME_SIZE);

  long MAX_PATH_SIZE = pathconf(".", _PC_PATH_MAX);
  printf( "_PC_PATH_MAX: %ld\n\n", MAX_PATH_SIZE);

  return 0;
}

$ gcc -o name-max name-max.c && ./name-max 
saddr.sun_path: 108

_PC_NAME_MAX: 255

_PC_PATH_MAX: 4096

So yes it appears that on most other platforms sizeof(saddr.sun_path) is less than NAME_MAX