Re: [whatwg/url] Addressing HTTP servers over Unix domain sockets (#577)

@jdimpson
> Allowing use of DNS to resolve a URI to a Unix Domain Socket path sounds like a wonderful gift to hand to malevolent actors.

To review, the topic of this discussion is "Addressing HTTP servers over Unix domain sockets".  And now, addressing that goal, I have proposed interpreting an RFC 3986 "URI" - which is what is implied by the phrase "Addressing HTTP servers" in the title - more generally, so as to successfully resolve an AF_UNIX socket  "filesystem pathname", as defined in `man 7 unix`.  A "filesystem pathname" is more specifically defined in "POSIX.1-2024", under "3.254 Pathname", here:
https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap03.html#tag_03_254

It is important to note that an AF_UNIX "address" has a format different from other socket address families, where RFC 3986 is especially biased in support of AF_INET and AF_INET6 sockets.

Also, `man 7 unix` tells us:
```
       The  AF_UNIX  (also  known  as  AF_LOCAL)  socket  family  is  used to communicate between
       processes on the same machine efficiently.  Traditionally,  UNIX  domain  sockets  can  be
       either unnamed, or bound to a filesystem pathname (marked as being of type socket).
```
where "efficiently" generally implies side-stepping use otherwise of the local machine's IP stack.

And, while use of an AF_UNIX socket is "to communicate between processes on the same machine", at the same time, the meaning of "Addressing HTTP servers", again, implies use of an RFC 3986 "URI", which itself is subject to additional standards recommendations.

For instance, RFC 4007 extends the Textual Representation of an IPv6 address to include a "zone_id", using the "%" character as a delimiter, and  RFC 6874 extends the definition of the RFC 3986 "URI" to address the use of this "%" delimiter, otherwise always treated as an escape character in a URI, such that the "%" character is replaced by its equivalent "escaped" representation, "%25":
```
      IPv6addrz = IPv6address "%25" ZoneID
```
Of course *any* delimiter, for whatever purpose, might be represented using an escaped character sequence, but RFC 6874 only apples to an IPv6 "ZoneID", and is of no use in IPv4 addresses, to otherwise describe an AF_UNIX "Pathname" address as a kind of "ZoneID".

More recently, 2020 June, RFC 8820, "URI Design and Ownership" contains some rather pointed comments warning about overly rigid, difficult, or presumptuous interpretations of the RFC 3986 "URI".  For example,  RFC 8615, "Well-Known Uniform Resource Identifiers (URIs)", extends the interpretation of the URI "path":
```
   A well-known URI is a URI [RFC3986] whose path component begins with
   the characters "/.well-known/", provided that the scheme is
   explicitly defined to support well-known URIs.
```
But, then it goes on to say:
```
   Applications that wish to mint new well-known URIs MUST register
   them, following the procedures in Section 5.1, subject to the
   following requirements.

   Registered names MUST conform to the "segment-nz" production in
   [RFC3986].  This means they cannot contain the "/" character.
```
So, a UDS pathname  could not, itself, be used as a "/.well-known/" registered name in a URI.  Still, a UDS pathname could be modified in other ways, such as using the escaped "/" character, "%2F".  But "/.well-known/" registered names seem an unnecessarily complicated approach to accommodating every different address style in every different address family to be found in `man 7 address_families`.

More generally, the goal in addressing the question raised in this discussion is to provide a simple URI mechanism to accommodate the varied "address" formats used in the many `man 2 socket` "address families".  I have suggested that a single ":" delimiter is a pretty simple and effective solution.

Now, to your point, you seem to be suggesting that some security conscious System Administrator, for example, such as yourself, would configure a publicly accessible server to provide open access to a UDS, and thereby, leave the system vulnerable to some kind of security breach.  Is that correct?

Please explain - Why would you do that?  Can you provide an example?

There is no standards specification which requires any computer system, networked or not, to provide open access to a UDS.  In fact, there are quite a number of mechanisms, already in use, to allow a System Administrator to restrict access to system resources, especially including any networked computer system.

What prevents a System Administrator from making use of those security measures with respect to a UDS, as compared to any other socket family, and especially, as compared to AF_INET and AF_INET6 sockets?



-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/issues/577#issuecomment-2608372348
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/url/issues/577/2608372348@github.com>