On Tue, 24 Dec 2019, 14:17 Neil Horman, <nhorman(a)redhat.com> wrote:
>Right, Usually the workaround is to >convert to using
anonymous sockets,
>storing
>correlary information to find the >socket later using non-fs based
>methods.
>Neil
IIRC this would be done at an application level. This issue here is IMHO
with flatpak applications (many electron applications, gnome boxes
and
others) to work by incident basically, as the default cache config an data
paths is HOME/var/.App/appid
A slightly longer username already breaks all these flatpak
applications.
> On Tue, Dec 24, 2019 at 12:39 AM Neil Horman
<nhorman(a)redhat.com> wrote:
> >
> > On Mon, Dec 23, 2019 at 10:48:16PM +0200, Damian Ivanov wrote:
> > > Hello everyone and Happy holidays!
> > >
> > > Some applications (like gnome-boxes) rely on socket path
> > >
https://gitlab.gnome.org/GNOME/gnome-boxes/issues/267
> > >
> > > A lot of flatpaks as well (filled report here
> > >
https://github.com/flatpak/flatpak/issues/3336 )
> > >
> > > If an organizations username structure is
> > > firstname.lastname(a)organization.org for example my username (more
than
> > > one first name, not to mentioned that in some regions middle-name's
> > > are used as well) would be 42 characters which exceeds the limit (17)
> > > mentioned in the gnome BR.
> > >
> > > 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?
> > >
> > > Do you think that this us something that could/should/would be
changed
> > > nowadays as a config option?
> > >
> > Its part of the unix protocol address specification (see man 7 unix).
Its hard
> > coded, and while the Single Unix Specification leaves it undefined,
once
> > selected, it becomes part of the ABI, and so it can't easily be
changed without
> > breaking older user space applications.
> >
> > Neil
> >
> > > Thanks in advance!
> > > Best Regards,
> > > Damian
> > > _______________________________________________
> > > kernel mailing list -- kernel(a)lists.fedoraproject.org
> > > To unsubscribe send an email to kernel-leave(a)lists.fedoraproject.org
> > > 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@lists.fedoraproject.org
> >
>