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
If referencing an AF_UNIX stream socket to connect to, the connection will originate from an abstract namespace socket, that includes information about the unit and the credential ID in its socket name. Use getpeername(2) to query this information. The returned socket name is formatted as NUL RANDOM "/unit/" UNIT "/" ID, i.e. a NUL byte (as required for abstract namespace socket names), followed by a random string (consisting of alphadecimal characters), followed by the literal string "/unit/", followed by the requesting unit name, followed by the literal character "/", followed by the textual credential ID requested. Example: "\0adf9d86b6eda275e/unit/foobar.service/credx" in case the credential "credx" is requested for a unit "foobar.service". This functionality is useful for using a single listening socket to serve credentials to multiple consumers.
I wonder how many users would be for such feature to add module that would support this protocol to generate credentials on the fly.
The API could be exposed as a wrapper on gen_server that would listen on given socket, parse peer name, and then call 2-ary function (first argument would contain unit name, second credential ID).
The text was updated successfully, but these errors were encountered:
Quoting docs:
I wonder how many users would be for such feature to add module that would support this protocol to generate credentials on the fly.
The API could be exposed as a wrapper on
gen_server
that would listen on given socket, parse peer name, and then call 2-ary function (first argument would contain unit name, second credential ID).The text was updated successfully, but these errors were encountered: