Binding to privileged ports on Mac OS

[jmezach]

I'm trying to get my Aspire AppHost to have a YARP resource bind to port 443 which works just fine on Windows, but I'm having some issues on Mac OS. As noted in microsoft/aspire#5508 (comment) there is a way on Mac OS to bind to a privileged port without having to run as root, but you have to bind to all addresses. So I used the following in my AppHost:

var gateway = builder.AddYarp("gateway")
       .WithEndpoint("https", e =>
       {
           e.UriScheme = "https";
           e.TargetPort = 5001;
           e.Port = 443;
           e.TargetHost = "0.0.0.0";
       })

I was hoping this would solve my issue, but it still wouldn't bind to port 443 and basically just fail silently. After doing some digging I think I've narrowed it down to how dcp works. Looking at the LookupIP function it handles 0.0.0.0 specifically to the IP addresses of all the network interfaces on the machine. So when it comes to creating the proxy it will effectively use the IP address of my network interface which results in a permission denied.

I have reproduced this by writing a small Go program with the following code:

package main

import (
	"context"
	"fmt"
	"net"
)

func main() {
	lc := net.ListenConfig{}
	tcpListener, err := lc.Listen(context.Background(), "tcp", AddressAndPort("192.168.40.118", 443))
	if err != nil {
		fmt.Println("Error:", err)
		return
	}

	// The listener is now bound, wait for a key press to close it
	fmt.Println("Listener is bound. Press Enter to close.")
	fmt.Scanln()

	defer tcpListener.Close()
}

func AddressAndPort(address string, port int32) string {
	return fmt.Sprintf("%s:%d", address, port)
}

Running this with go run test.go results in Error: listen tcp 192.168.40.118:443: bind: permission denied

If I simply change the first parameter to AddressAndPort to be "0.0.0.0" I get the following output: Listener is bound. Press Enter to close. At that point I'm able to connect to that port as well.

Now I'm left wondering why ListenIP resolves 0.0.0.0 to all local network interface IPs. It does call-out that this must be done manually, so there's probably a good reason for it, so what am I missing here?

[karolz-ms]

Thank you for filing the issue.

The reason we resolve 0.0.0.0 ourselves in DCP code is because we wanted to make sure that all the addresses use the same port number AND also honor the IPv4 vs IPv6 preferences as specified by the DCP_IP_VERSION_PREFERENCE environment variable. At the time the code was written I could not find a way to do so using high-level API like ListenerConfig.Listen (at least not without actually listening on the port, which we want to avoid on DCP side unless strictly necessary), and the lower-level API (net.LookupIP) did not resolve 0.0.0.0 like the comment indicates.

For my education: is there a particular reason why non-privileged port use is less preferable in your application?

[jmezach]

@karolz-ms Thank you for that explanation. I guess I understand the desire there, but as far as I know Aspire doesn't use DCP_IP_VERSION_PREFERENCE and doesn't explicitly specifying 0.0.0.0 already kind of imply IPv4 regardless?

Our primary motivation for running our application on port 443 is CORS and OpenID Connect. We have a fairly large micro-services landscape and what we're trying to do is to create a local development environment that only runs a bare-minimum of services on the local machine but having the ability to re-use some of the services on a remote test environment. In order for this to work we have to sign-in to the test environments OIDC server which will then have to redirect back to the application running on our local development environment, so having a stable HTTPS URL is beneficial there. The same applies for CORS since it treats https://localhost:5001 as a different origin than https://localhost:5000, so again having a stable local URL means we don't have to reconfigure things every time.

As I'm thinking through this though I guess we could just hardcode the ports and always use the same to avoid these issues as well.

[karolz-ms]

@jmezach it is true that Aspire does not use the version preference environment variable directly, but it remains an important "escape hatch" for people who work in environments where the use of IPv4 or IPv6 is constrained for some reason.

I completely understand the need for stable callback URLs for authentication flows; in fact authN via OpenID Connect is probably the most important reason why Aspire leaned so heavily on having first class HTTPS support. What I am curious about is whether 443 is required and why, as opposed to using non-privileged range port.