[Libguestfs] [PATCH libnbd v2 3/4] generator: Add APIs to get/set the socket activation socket name

[Laszlo Ersek]

On 1/31/23 19:03, Eric Blake wrote:
> On Tue, Jan 31, 2023 at 05:28:18PM +0000, Richard W.M. Jones wrote:
>>>> +  /* Check the proposed name is short and alphanumeric. */
>>>> +  if (len > 32) {
>>>> +    set_error (ENAMETOOLONG, "socket activation name should be "
>>>> +               "<= 32 characters");
>>>
>>> I don't mind keeping us strict to start with and loosening it later if
>>> someone demonstrates why it is needed.  But systemd documents a larger
>>> set of possible names:
>>>
>>> https://www.freedesktop.org/software/systemd/man/sd_pid_notify_with_fds.html
>>>
>>> FDNAME=…
>>>
>>>     When used in combination with FDSTORE=1, specifies a name for the
>>>     submitted file descriptors. When used with FDSTOREREMOVE=1,
>>>     specifies the name for the file descriptors to remove. This name
>>>     is passed to the service during activation, and may be queried
>>>     using sd_listen_fds_with_names(3). File descriptors submitted
>>>     without this field set, will implicitly get the name "stored"
>>>     assigned. Note that, if multiple file descriptors are submitted at
>>>     once, the specified name will be assigned to all of them. In order
>>>     to assign different names to submitted file descriptors, submit
>>>     them in separate invocations of sd_pid_notify_with_fds(). The name
>>>     may consist of arbitrary ASCII characters except control
>>>     characters or ":". It may not be longer than 255 characters. If a
>>>     submitted name does not follow these restrictions, it is ignored.
>>
>> I didn't know about this documentation before.
> 
> I only found it this morning.
> 
>>
>> Arbitrary ASCII characters doesn't sound that great though.  I'm sure
>> that q-s-d will want its own much more strict limitations, eg. I
>> assume you can't possibly support any characters which are meaningful
>> to JSON / QMP.  Any thoughts on that?
> 
> You have a strong point there.  Just because systemd allows it doesn't
> make it wise; I'm a big fan of "it's easier to resrict now and loosen
> later when we see the need", as being easier than "let's try and be as
> loose as we can now, then regret it later when we find it was a
> security hole".  Limiting to alphanumeric and 32 bytes until someone
> proves they have a use case for needing more than that works for me.

I agree!

Laszlo