On Thu, Jan 02, 2020 at 05:44:04PM +0100, Florian Weimer wrote: > * Neil Horman: > > > On Thu, Jan 02, 2020 at 02:35:22PM +0100, Florian Weimer wrote: > >> * Damian Ivanov: > >> > >> > I could not find any information if having the socket length limited > >> > is still something that is required nowadays as it seems this is > >> > mostly for compatibility reasons? > >> > >> I don't know why the kernel limits the socket length. There is no > >> strict requirement to do so because the userspace interfaces all have > >> explicit lengths. struct sockaddr_un has a fixed-size buffer, but > >> that could be worked around, similar to struct dirent. > >> > > The kernel doesn't limit this length for any particular technical > > reason, it limits it as a matter of maintaining ABI compatibility. > > When the unix address family was written back in the 80's, they > > decided that the sun_path component was coded to a length of 108 > > bytes, and so that is now part of the ABI, and can't be changed. > > Any systemcall expecting a strict 108 byte path may encounter what > > would appear to be an unterminated string, even if the only thing > > you did was lengthen the path name. > > The kernel would return an error in this case. It would be similar to > readlink with a buffer that is to small. The situation is actually > far more benign than with struct dirent, where the kernel happily > returns data that does not fit in the d_name array. > You're welcome to propose that, but I'm fairly certain it will get shot down. The use of any variable length array will mean no real size checking can be done without adding a length field that would break the ABI. You could increase the size to PATH_MAX or some such, but its going to devolve into an argument over what a sane size is for a structure that gets copied between user and kernel space Other solutions already exist (i.e. using socketpair or creating sockets in shorter paths and using symlinks). Neil _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
