You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On Windows the collector (usually) runs as a Control Panel Service process and therefore inherits whatever system identity (LOCAL SERVICE). Logging the username of the collector in the OTLP data stream is not very useful.
We should use the feature of named pipes to get the (Windows) SID of the client process upon receiving an incoming named pipe connection and map that to a username and log that.
This is PII-sensitive, so it should only be done if requested in the pii.yml.
On Linux/Mac Unix domain sockets have a similar feature and IIRC is already being used.
The text was updated successfully, but these errors were encountered:
To get the client peer data you need the OS handle to the pipe (rather than just the GO wrapper). This wasn't available at the time, so I couldn't do it then. But now that I've forked the relevant parts of the go-winio libraries to handle the multi-threaded problems, we can hack it a little further to get the peer data.
On Windows the collector (usually) runs as a Control Panel Service process and therefore inherits whatever system identity (LOCAL SERVICE). Logging the username of the collector in the OTLP data stream is not very useful.
We should use the feature of named pipes to get the (Windows) SID of the client process upon receiving an incoming named pipe connection and map that to a username and log that.
This is PII-sensitive, so it should only be done if requested in the
pii.yml
.On Linux/Mac Unix domain sockets have a similar feature and IIRC is already being used.
The text was updated successfully, but these errors were encountered: