Subject: Re: getaddrinfo() and PF_LOCAL
To: None <email@example.com>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 08/03/2001 10:40:07
>> why does AF_LOCAL still have anything to do with the filesystem?
>> Whether there is reason enough to preserve the filesystem semantics
>> is debatable.
> having it in the filesystem is not that much of a problem,
Big problem for some things, though we tend not to notice because
things that need filesystem-free sockets don't get done because there
aren't filesystem-free sockets. (Except 127.0.0.1 AF_INET sockets,
which lose compared to AF_LOCAL in various ways.)
The ability to put them in the filesystem and leverage the filesystem
access-control mechanisms, that's good. Having no option but putting
them in the filesystem, that's a lose.
Unfortunately I'm not sure there's much that can be done about it. I
don't for a moment think we're going to actually trash compatability
with historical AF_UNIX behavior. If this mistake had been caught
before AF_LOCAL were made a synonym for AF_UNIX, it could have been
corrected by adding a "flavor" field of some sort to the AF_LOCAL
sockaddr, thereby allowing multiple paradigms (eg, filesystem and
non-filesystem) for addressing. Now, the only alternative is to use a
new AF number.
Or ignore the issue and continue telling anyone who wants local sockets
freed of filesystem restrictions to use AF_INET 127.0.0.1, thereby
preventing them from passing access rights, requiring INET-capable
kernels, etc. Perhaps that'll be considered acceptable.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML firstname.lastname@example.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B