2:48 p.m.
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?
Thanks in advance!
Best Regards,
Damian
4:39 p.m.
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
10:10 p.m.
it becomes part of the ABI, and so it can't easily be changed
without
breaking older user space applications.
Thanks! Those keywords are enough to be
kinda sure this is a non-go
for a while...
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
>
6:17 a.m.
On Tue, Dec 24, 2019 at 06:10:03AM +0200, Damian Ivanov wrote:
>it becomes part of the ABI, and so it can't easily be changed
without
>breaking older user space applications.
Thanks! Those keywords are enough to be kinda sure this is a non-go
for a while...
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
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
>
9:02 a.m.
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
> >
>
3:52 p.m.
On Tue, Dec 24, 2019 at 05:02:54PM +0200, Damian Ivanov wrote:
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.
So, is it flatpak thats creating these sockets then? If thats the case, maybe
adjust flatpak to store sockets in /tmp/<nonce>/<id>, and symlink to them
from
$HOME/var/.App/appid?
Alternatively, just store text files in $HOME/var/.app/appid, and store the
socket descriptor that you want to use in said text file
Neil
> > 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
> > >
> >
>
>
4:45 a.m.
On Tue, 24 Dec 2019, 23:52 Neil Horman, <nhorman(a)redhat.com> wrote:
On Tue, Dec 24, 2019 at 05:02:54PM
So, is it flatpak thats creating these sockets then? If thats the case,
maybe
adjust flatpak to store sockets in /tmp/<nonce>/<id>, and symlink to them
from
$HOME/var/.App/appid?
Alternatively, just store text files in $HOME/var/.app/appid, and store the
socket descriptor that you want to use in said text file
Neil
Not flatpak creates them the application provided as flatpak does. What
flatpak should do is properly workaround this instead of relying on
accident that an application works.
4:48 a.m.
On Tue, 24 Dec 2019, 23:52 Neil Horman, <nhorman(a)redhat.com> wrote:
On Tue, Dec 24, 2019 at 05:02:54PM
So, is it flatpak thats creating these sockets then? If thats the case,
maybe
adjust flatpak to store sockets in /tmp/<nonce>/<id>, and symlink to them
from
$HOME/var/.App/appid?
Alternatively, just store text files in $HOME/var/.app/appid, and store the
socket descriptor that you want to use in said text file
Neil
Merry Christmas to everyone!
Not flatpak creates them the application provided as flatpak does. What
flatpak should do is properly workaround this instead of relying on
accident that an application works. I have a workaround changing the
default flatpak directory but flatpak devs should find a proper way to do
this...
On Wed, 25 Dec 2019, 12:45 Damian Ivanov, <damianatorrpm(a)gmail.com> wrote:
On Tue, 24 Dec 2019, 23:52 Neil Horman, <nhorman(a)redhat.com> wrote:
> On Tue, Dec 24, 2019 at 05:02:54PM
> So, is it flatpak thats creating these sockets then? If thats the case,
> maybe
> adjust flatpak to store sockets in /tmp/<nonce>/<id>, and symlink to
them
> from
> $HOME/var/.App/appid?
>
> Alternatively, just store text files in $HOME/var/.app/appid, and store
> the
> socket descriptor that you want to use in said text file
>
> Neil
Not flatpak creates them the application provided as flatpak does. What
flatpak should do is properly workaround this instead of relying on
accident that an application works.
7:35 a.m.
* 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 internal kernel interfaces are built on top of struct
sockaddr_storage and do not pass explicit lengths, but those could be
changed.
10:28 a.m.
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. And migrating structure to an arbitrary length
string (using a variable array or some such), would completley break the ABI.
The internal kernel interfaces are built on top of struct
sockaddr_storage and do not pass explicit lengths, but those could be
changed.
_______________________________________________
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
10:44 a.m.
* 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.
12:05 p.m.
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
1576
days inactive
1586
days old
kernel@lists.fedoraproject.org
11 comments
3 participants
participants (3)
-
Damian Ivanov -
Florian Weimer -
Neil Horman