why not remove AF_LOCAL sockets on last close?

[Thor Simon]

Can anyone tell me why, exactly, we shouldn't remove bound AF_LOCAL
sockets from the filesystem on last close? The following test program
produces "second socket bind failed" on every system I've tested it on,
and seems to cover the only possible use case for this "feature"...

#include <sys/types.h>
#include <sys/socket.h>
#include <sys/un.h>
#include <stdio.h>
#include <err.h>
#include <sysexits.h>

main()
{

int s = socket(PF_LOCAL, SOCK_DGRAM, 0);

struct sockaddr_un sun;

sun.sun_family = AF_UNIX;
sun.sun_len = sizeof(sun);
strlcpy(sun.sun_path, "/tmp/testdir/skt", sizeof(sun.sun_path));

mkdir("/tmp/testdir", 0700);

if (bind(s, (struct sockaddr *)&sun, sun.sun_len)) {
err(EX_OSERR, "first socket bind failed");
}

close(s);
s = socket(PF_LOCAL, SOCK_DGRAM, 0);

chmod("/tmp/testdir", 0500);
if (bind(s, (struct sockaddr *)&sun, sun.sun_len)) {
err(EX_NOPERM, "second socket bind failed");
}
}


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Matthias Scheler]

Post by Thor Simon
Can anyone tell me why, exactly, we shouldn't remove bound AF_LOCAL
sockets from the filesystem on last close?

I think of a reason for that as they are completely useless with
a process attached to them anyway.

Kind regards

[Greg Troxel]

Can anyone tell me why, exactly, we shouldn't remove bound AF_LOCAL
sockets from the filesystem on last close? The following test program
produces "second socket bind failed" on every system I've tested it on,
and seems to cover the only possible use case for this "feature"...

Have you looked at posix to see if it speaks to this? I don't think it
gets specific enough to say.

A reason might be that every other system behaves the same way and being
different will just lead to non-portable code.

[Matthew Mondor]

On Fri, 25 Jun 2010 09:19:03 -0400

I think this is (always has been) a considerable blind spot on the part
of BSD partisans. Sure, we're happy to gripe about persistent SysV IPC
objects every time we have to remember how to use ipcrm, but bound AF_UNIX
sockets have the same issue, and we just ignore it.

I don't think most people have trouble with SysV IPC, considering those
persistent resources were often used by short lived, but frequently used
commands/processes, utilising both the permissions and persistent
resources features (and NetBSD allows the admin to set the limit of the
various SysV resources with accuracy); admitedly we can now do the
same using files, mmap and advisory locks, though.

But I agree that if leaving the sockets around permits no interesting
feature whatsoever (i.e. it doesn't even serve for SO_REUSEADDR), it
very well could be a design or implementation bug, even if common
software already explicitely unlink AF_LOCAL sockets to account for
this issue...

[Matthew Mondor]

On Fri, 25 Jun 2010 08:59:18 -0400

However, I wrote a small test program and realized that despite
SO_REUSEADDR this doesn't work, and indeed after checking the kernel
code SO_REUSEADDR is ignored in the AF_LOCAL unp_bind() code.

Out of curiosity, I modified the test to see if immediately unlinking
the socket node after bind(2) would leave it around until it's closed, a
feature which some software expect for files on certain OS/FS
combinations.

However, the socket node is immediately deleted at unlink(2) even if
it's still open and bound, so an application also shouldn't rely on
this.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[der Mouse]

Post by Matthew Mondor
But I agree that if leaving the sockets around permits no interesting
feature whatsoever (i.e. it doesn't even serve for SO_REUSEADDR),

I've been trying to think of any such feature since this discussion
started. So far i've failed.

Post by Matthew Mondor
it very well could be a design or implementation bug,

I suspect it is actually not so much a design or implementation bug as
it is a historical accident: I suspect the initial implementation made
them a new inode type because it was a cheap and easy way to get a
namespace for free, and didn't bother with the impedance mismatch
between filesystem semantics and (other-AF) socket semantics because it
was just a quick experimental hack.

Then, as often happens, the quick experimental hack persisted long
beyond its initial experimental phase, with nobody fixing the semantics
because everybody was used to them and software was written to deal.

As I mentioned in another message a few minutes ago, I think this is
not easy to do fully right - indeed, it's not totally clear what
"right" is in all cases - but I do think it is easy to come close
enough to be useful.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[der Mouse]

Post by Greg Troxel
A reason might be that every other system behaves the same way and
being different will just lead to non-portable code.

Non-portable *how*? What exactly would happen?

I don't know, and if you've got an argument that code written for
either behavior will be ok both places I don't have a problem with
it. The only thing I can think of is that code that does an explicit
unlink and checks for error on the unlink may complain, which is
pretty mild.

Well, code that expects the automatic unlink is liable to break
unexpectedly (and probably cryptically) on "traditional" systems.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de