LoadCredential's unix domain socket support doesn't allow us to communicate that credential does no exist

[arianvp]

Component

other

Is your feature request related to a problem? Please describe

When pointing LoadCredential= at a unix domain socket; there is no way to communicate back to systems that the credential doesn't exist like with the file-based approach. I tried closing the unix domain socket connection but that just leads to an empty file being mounted in to the service.

Is there a way to communicate back from the listener's perspective that a credential doesn't exist?

Describe the solution you'd like

I wonder if it would be better if instead of using the source address as the credential name, we would just have some in-band communication protocol like Varlink. That'd also open up the possibility of reloading credentials over the socket, or loading multiple credentials over a single connection like LoadCredential= points to a directory.****

Describe alternatives you've considered

Not used systemd credentials

The systemd version you checked that didn't have the feature you are asking for

253

[arianvp]

Example code where I am running into this issue:

https://github.com/arianvp/systemd-creds/blob/1490f6afad309dccce89bc44cb326b55ca8f161b/server/server.go#L52-L59

[poettering]

hmm, the current "protocol" is designed to transfer creds, not to not transfer them ;-)

i guess we could change things so that an empty cred is automatically suppressed. people who actually want empty creds could then combine LoadCredential= with SetCredential= on the same credential, and assign an empty string that way.

But yeah, you have a point, something like varlink becomes tempting for this...

[poettering]

So, as discussed elsewhere: we should tweak systemd's logic so that the socket can also be an AF_UNIX/SOCK_SEQPACKET socket. Then we'll try to read exactly one datagram off it. If it works (even if zero sized) it's a valid datagram. If however the server disconnects our connection before sending us a single datagram it would mean "go away, i have no cred for your".

Sounds simple enough.

[DaanDeMeyer]

So, as discussed elsewhere: we should tweak systemd's logic so that the socket can also be an AF_UNIX/SOCK_SEQPACKET socket. Then we'll try to read exactly one datagram off it. If it works (even if zero sized) it's a valid datagram. If however the server disconnects our connection before sending us a single datagram it would mean "go away, i have no cred for your".

There was also a request to allow sending multiple credentials over a single AF_UNIX socket, maybe we can do that with SEQPACKET as well somehow?

[poettering]

There was also a request to allow sending multiple credentials over a single AF_UNIX socket, maybe we can do that with SEQPACKET as well somehow?

hmm, what does that mean? "allow sending multiple credentials"?

[DaanDeMeyer]

hmm, what does that mean? "allow sending multiple credentials"?

To allow services to configure a credential glob (e.g. my-service.*) along with an AF_UNIX socket to retrieve all the credentials registered for that service.

[arianvp]

For example when you point LoadCredential= at a directory all the files in that directory are loaded.
It would be nice to have the an analogue for that behaviour for the unix domain socket protocol.

This is because most secret management products (AWS Secret manager, Google secret manager, Vault, Kubernetes Secrets) model secrets as directories with to key-value pairs at the leafs of the tree

# Path: secret/my-certificate
{
key.pem: <blah>,
key.crt: <blah2>,
}

so would be useful if I have LoadCredential=my-certificate:/run/mysock that it loads both key.pem and key.crt

and would put them in $CREDENTIALS_DIRECTORY/my-certificate/{key.pem,key.crt} just like when I'd point to /run/credstore/my-certificate

[arianvp]

Can we distinguish "0" bytes vs "stream was closed" with SEQPACKET? that'd solve the ambiguity of file doesn't exist vs file is empty on getting an EOF

[poettering]

Can we distinguish "0" bytes vs "stream was closed" with SEQPACKET? that'd solve the ambiguity of file doesn't exist vs file is empty on getting an EOF

yes