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.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization:
qemu.org |
libvirt.org