5 added 5 characters in body
source | link

I posted this question over a year ago and was never quite satisfied with the lack of definitive documentation. I thought I'd check Linux documentation again for any updates, and was happy to see this:

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 fchmod(2)) has no effect on the accessibility of the socket.

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

Also, The Linux Programming Interface by Michael Kerrisk covers the question (cross-posted from this other answer):

57.6 The Linux Abstract Socket Namespace

The so-called abstract namespace is a Linux-specific feature that allows us to bind a UNIX domain socket to a name without that name being created in the file system. This provides a few potential advantages:

  • We don’t need to worry about possible collisions with existing names in the file system.
  • It is not necessary to unlink the socket pathname when we have finished using the socket. The abstract name is automatically removed when the socket is closed.
  • We don’t need to create a file-system pathname for the socket. This may be useful in a chroot environment, or if we don’t have write access to a file system.

To create an abstract binding, we specify the first byte of the sun_path field as a null byte (\0). [...]

I reckon that, along with @user3188445's answer, this clears the question up very precisely.

That said, there's still an assumption made here, that processes which are SIGKILL'd will have all open sockets closed. That seems a reasonable assumption, but I don't have documentation that defines that behavior.

I posted this question over a year ago and was never quite satisfied with the lack of definitive documentation. I thought I'd check Linux documentation again for any updates, and was happy to see this:

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 fchmod(2)) has no effect on the accessibility of the socket.

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

Also, The Linux Programming Interface by Michael Kerrisk covers the question (cross-posted from this other answer):

57.6 The Linux Abstract Socket Namespace

The so-called abstract namespace is a Linux-specific feature that allows us to bind a UNIX domain socket to a name without that name being created in the file system. This provides a few potential advantages:

  • We don’t need to worry about possible collisions with existing names in the file system.
  • It is not necessary to unlink the socket pathname when we have finished using the socket. The abstract name is automatically removed when the socket is closed.
  • We don’t need to create a file-system pathname for the socket. This may be useful in a chroot environment, or if we don’t have write access to a file system.

To create an abstract binding, we specify the first byte of the sun_path field as a null byte (\0). [...]

I reckon that, along with @user3188445's answer, clears the question up very precisely.

That said, there's still an assumption made here, that processes which are SIGKILL'd will have all open sockets closed. That seems a reasonable assumption, but I don't have documentation that defines that behavior.

I posted this question over a year ago and was never quite satisfied with the lack of definitive documentation. I thought I'd check Linux documentation again for any updates, and was happy to see this:

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 fchmod(2)) has no effect on the accessibility of the socket.

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

Also, The Linux Programming Interface by Michael Kerrisk covers the question (cross-posted from this other answer):

57.6 The Linux Abstract Socket Namespace

The so-called abstract namespace is a Linux-specific feature that allows us to bind a UNIX domain socket to a name without that name being created in the file system. This provides a few potential advantages:

  • We don’t need to worry about possible collisions with existing names in the file system.
  • It is not necessary to unlink the socket pathname when we have finished using the socket. The abstract name is automatically removed when the socket is closed.
  • We don’t need to create a file-system pathname for the socket. This may be useful in a chroot environment, or if we don’t have write access to a file system.

To create an abstract binding, we specify the first byte of the sun_path field as a null byte (\0). [...]

I reckon that, along with @user3188445's answer, this clears the question up very precisely.

That said, there's still an assumption made here, that processes which are SIGKILL'd will have all open sockets closed. That seems a reasonable assumption, but I don't have documentation that defines that behavior.

4 added 35 characters in body
source | link

I posted this question over a year ago and was never quite satisfied with the lack of definitive documentation. I thought I'd check Linux documentation again for any updates, and was happy to see this:

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 fchmod(2)) has no effect on the accessibility of the socket.

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

Also, The Linux Programming Interface by Michael Kerrisk covers the question (cross-posted from this other answer):

57.6 The Linux Abstract Socket Namespace

The so-called abstract namespace is a Linux-specific feature that allows us to bind a UNIX domain socket to a name without that name being created in the file system. This provides a few potential advantages:

  • We don’t need to worry about possible collisions with existing names in the file system.
  • It is not necessary to unlink the socket pathname when we have finished using the socket. The abstract name is automatically removed when the socket is closed.
  • We don’t need to create a file-system pathname for the socket. This may be useful in a chroot environment, or if we don’t have write access to a file system.

To create an abstract binding, we specify the first byte of the sun_path field as a null byte (\0). [...]

I reckon that, along with @user3188445's answer, clears the question up very precisely.

That said, there's still an assumption made here, that processes which are SIGKILL'd will have all open sockets closed. That seems a reasonable assumption, but I don't have documentation that defines that behavior.

I posted this question over a year ago and was never quite satisfied with the lack of definitive documentation. I thought I'd check Linux documentation again for any updates, and was happy to see this:

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 fchmod(2)) has no effect on the accessibility of the socket.

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

Also, The Linux Programming Interface by Michael Kerrisk covers the question (cross-posted from this other answer):

57.6 The Linux Abstract Socket Namespace

The so-called abstract namespace is a Linux-specific feature that allows us to bind a UNIX domain socket to a name without that name being created in the file system. This provides a few potential advantages:

  • We don’t need to worry about possible collisions with existing names in the file system.
  • It is not necessary to unlink the socket pathname when we have finished using the socket. The abstract name is automatically removed when the socket is closed.
  • We don’t need to create a file-system pathname for the socket. This may be useful in a chroot environment, or if we don’t have write access to a file system.

To create an abstract binding, we specify the first byte of the sun_path field as a null byte (\0). [...]

I reckon that clears the question up very precisely.

That said, there's still an assumption made here, that processes which are SIGKILL'd will have all open sockets closed. That seems a reasonable assumption, but I don't have documentation that defines that behavior.

I posted this question over a year ago and was never quite satisfied with the lack of definitive documentation. I thought I'd check Linux documentation again for any updates, and was happy to see this:

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 fchmod(2)) has no effect on the accessibility of the socket.

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

Also, The Linux Programming Interface by Michael Kerrisk covers the question (cross-posted from this other answer):

57.6 The Linux Abstract Socket Namespace

The so-called abstract namespace is a Linux-specific feature that allows us to bind a UNIX domain socket to a name without that name being created in the file system. This provides a few potential advantages:

  • We don’t need to worry about possible collisions with existing names in the file system.
  • It is not necessary to unlink the socket pathname when we have finished using the socket. The abstract name is automatically removed when the socket is closed.
  • We don’t need to create a file-system pathname for the socket. This may be useful in a chroot environment, or if we don’t have write access to a file system.

To create an abstract binding, we specify the first byte of the sun_path field as a null byte (\0). [...]

I reckon that, along with @user3188445's answer, clears the question up very precisely.

That said, there's still an assumption made here, that processes which are SIGKILL'd will have all open sockets closed. That seems a reasonable assumption, but I don't have documentation that defines that behavior.

3 added 217 characters in body
source | link

I posted this question over a year ago and was never quite satisfied with the lack of definitive documentation. I thought I'd check Linux documentation again for any updates, and was happy to see this:

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 fchmod(2)) has no effect on the accessibility of the socket.

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

Also, The Linux Programming Interface by Michael Kerrisk covers the question (cross-posted from this other answer):

57.6 The Linux Abstract Socket Namespace

The so-called abstract namespace is a Linux-specific feature that allows us to bind a UNIX domain socket to a name without that name being created in the file system. This provides a few potential advantages:

  • We don’t need to worry about possible collisions with existing names in the file system.
  • It is not necessary to unlink the socket pathname when we have finished using the socket. The abstract name is automatically removed when the socket is closed.
  • We don’t need to create a file-system pathname for the socket. This may be useful in a chroot environment, or if we don’t have write access to a file system.

To create an abstract binding, we specify the first byte of the sun_path field as a null byte (\0). [...]

I reckon that clears the question up very precisely.

That said, there's still an assumption made here, that processes which are SIGKILL'd will have all open sockets closed. That seems a reasonable assumption, but I don't have documentation that defines that behavior.

I posted this question over a year ago and was never quite satisfied with the lack of definitive documentation. I thought I'd check Linux documentation again for any updates, and was happy to see this:

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 fchmod(2)) has no effect on the accessibility of the socket.

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

Also, The Linux Programming Interface by Michael Kerrisk covers the question (cross-posted from this other answer):

57.6 The Linux Abstract Socket Namespace

The so-called abstract namespace is a Linux-specific feature that allows us to bind a UNIX domain socket to a name without that name being created in the file system. This provides a few potential advantages:

  • We don’t need to worry about possible collisions with existing names in the file system.
  • It is not necessary to unlink the socket pathname when we have finished using the socket. The abstract name is automatically removed when the socket is closed.
  • We don’t need to create a file-system pathname for the socket. This may be useful in a chroot environment, or if we don’t have write access to a file system.

To create an abstract binding, we specify the first byte of the sun_path field as a null byte (\0). [...]

I reckon that clears the question up very precisely.

I posted this question over a year ago and was never quite satisfied with the lack of definitive documentation. I thought I'd check Linux documentation again for any updates, and was happy to see this:

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 fchmod(2)) has no effect on the accessibility of the socket.

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

Also, The Linux Programming Interface by Michael Kerrisk covers the question (cross-posted from this other answer):

57.6 The Linux Abstract Socket Namespace

The so-called abstract namespace is a Linux-specific feature that allows us to bind a UNIX domain socket to a name without that name being created in the file system. This provides a few potential advantages:

  • We don’t need to worry about possible collisions with existing names in the file system.
  • It is not necessary to unlink the socket pathname when we have finished using the socket. The abstract name is automatically removed when the socket is closed.
  • We don’t need to create a file-system pathname for the socket. This may be useful in a chroot environment, or if we don’t have write access to a file system.

To create an abstract binding, we specify the first byte of the sun_path field as a null byte (\0). [...]

I reckon that clears the question up very precisely.

That said, there's still an assumption made here, that processes which are SIGKILL'd will have all open sockets closed. That seems a reasonable assumption, but I don't have documentation that defines that behavior.

2 replaced http://unix.stackexchange.com/ with https://unix.stackexchange.com/
source | link
1
source | link