microsoft / omi

Open Management Infrastructure
Other
361 stars 115 forks source link

getaddrinfo calls with a service name fail on Docker images that lack /etc/services #623

Closed danports closed 5 years ago

danports commented 5 years ago

Certain Docker images (like mcr.microsoft.com/dotnet/core/runtime-deps:*-bionic/*-stretch-slim, based on Ubuntu/Debian) do not bundle /etc/services, which causes getaddrinfo calls with a service name to fail. I see only one place in this library where a service name is passed to getaddrinfo: https://github.com/Microsoft/omi/blob/5a2a017f48f616b209d72316bfc8a701ce089a7a/Unix/http/httpclientauth.c#L2565

On affected Docker images, this problem results in authentication failing with a misleading MI_RESULT_ACCESS_DENIED error, and various downstream issues (e.g. you can't use the PowerShell SDK in a Linux .NET Core container running one of the official images listed above to connect to a Windows machine via WSMan).

JumpingYang001 commented 5 years ago

@danports any suggestion about how to fix it?

JumpingYang001 commented 5 years ago

@danports in fact, omi don't officially support PowerShell now, so I think we might not fix it ...

danports commented 5 years ago

To be clear, this is a problem in this library, not in PowerShell. I am definitely not an expert in this area and haven't tested this, but from what I've read, it should be possible to fix this by passing a string containing a port number (e.g. "80") to getaddrinfo rather than "http".

JumpingYang001 commented 5 years ago

80 is a fixed number, I don't think it is a good solution.

danports commented 5 years ago

True, 80 is a fixed number, but what is the risk of the HTTP port changing? Furthermore, it doesn't look like the port passed into the call even matters - the code only uses the ai_canonname field of the addrinfo struct. It doesn't pass the addrinfo struct to connect, so the port number is irrelevant. "http" could be changed to any valid port number passed as a string.

JumpingYang001 commented 5 years ago

won't fix.

danports commented 5 years ago

I am very puzzled by your decision to leave this bug unaddressed, especially considering the workaround is so simple. But the decision is yours to make, and I will respect that.

JumpingYang001 commented 5 years ago

@danports you can new a PR to fix it as PowerShell is not in our scope now.

danports commented 5 years ago

Alright, I opened https://github.com/microsoft/omi/pull/631. Just to clarify, this is an issue in this library whether it is used in the PowerShell stack or not.