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 _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs