[issue8882] socketmodule.c`getsockaddrarg() should not check the length of sun_path
A.M. Kuchling added the comment: No changes seems to be necessary, per MvL's comment. -- nosy: +akuchling resolution: - wont fix stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8882 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8882] socketmodule.c`getsockaddrarg() should not check the length of sun_path
Changes by Sébastien Sablé sa...@users.sourceforge.net: -- nosy: +sable ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8882 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8882] socketmodule.c`getsockaddrarg() should not check the length of sun_path
Edward Pilatowicz edward.pilatow...@oracle.com added the comment: some additional data. AIX 6.1: defined sun_path = 1023 max sun_path = 1023 i'll also point out the existence of the SUN_LEN() macro, which is defined on all the previously mentioned operating systems, and which calculates the size of a sockaddr_un structure using strlen() of sun_path, not sizeof(). that said, as a counter argument, UNIX Network Programming by Richard Stevens explicitly mentions that the use of sizeof() is ok. still, personally, i think it's pretty risky for an OS to change this definition. (it seems that AIX is the only OS i've seen that has done so.) i say this because use of the sockaddr_un structure is so prevalent. it's commonly embedded into other structures and passed around via APIs that (unlike bind(), connect(), etc) don't take a size parameter which specifies the size of the structure. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8882 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8882] socketmodule.c`getsockaddrarg() should not check the length of sun_path
Martin v. Löwis mar...@v.loewis.de added the comment:
Applications should not assume a particular length for sun_path or
assume that it can hold {_POSIX_PATH_MAX} characters (255).
hence, it seems to me that python should not actually be doing any size
checks on the path passed to getsockaddrarg().
You are misinterpreting the specification. What they say is that the
right way of doing it is the way Python currently does it.
not assume a particular length means not assume, in the source code,
and specific fixed length, such as 108, or 255. Now, if the program
must not assume any specific length, it must use sizeof instead to
determine how large sun_path is.
If your operating system declares sun_path to be shorter than the
strings it actually supports, complain to your operating system vendor
that they fix their header files.
--
nosy: +loewis
title: socketmodule.c`getsockaddrarg() should not check the length of sun_path
- socketmodule.c`getsockaddrarg() should not check the length of sun_path
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8882
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8882] socketmodule.c`getsockaddrarg() should not check the length of sun_path
Edward Pilatowicz edward.pilatow...@oracle.com added the comment: so i wrote a simple test program that tells me the defined length of sun_path and then uses bind() with increasingly long paths to determine the actually supported length of sun_path. here's what i've found: Solaris: defined sun_path = 108 max sun_path = 1024 FreeBSD 8.0: defined sun_path = 104 max sun_path = 254 Fedora 11: defined sun_path = 108 max sun_path = 108 i have requested access to an AIX system to check what length of sun_path is defined and supported there. while i could request that this value be changed in the OS, that would likely cause problems with pre-existing compiled code. i'm guessing that most OS vendors would not be eager to update this value, which is probably why it's been the same small value for such a long time. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8882 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8882] socketmodule.c`getsockaddrarg() should not check the length of sun_path
New submission from Edward Pilatowicz edward.pilatow...@oracle.com:
recently i was writing some python code that attempted to bind a unix
domain socket to a long filesystem path. this code was failing and
telling me that the path name was too long. tracing python i saw that
it wasn't event issuing a system call for my bind() request. eventually
i tracked down the problem to socketmodule.c`getsockaddrarg():
http://svn.python.org/view/python/trunk/Modules/socketmodule.c?view=markup
there we see that getsockaddrarg() checks to verify that the specified
path is less than sizeof addr-sun_path, where addr is a struct
sockaddr_un. this seems incorrect to me.
on most systems sockaddr_un.sun_path is defined as a small character
array. this limit is an ancient bit of unix legacy and most modern
systems do not actually limit domain socket names to a path as short as
sun_path. on solaris the real limit is MAXPATHLEN, there by allowing
unix domain sockets to be bound to any filesystem path.
the posix specification also says that users of the sockaddr_un
structure should not make any assumptions about the maximum supported
length of sun_path.
from:
http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/un.h.html
we have:
charsun_path[]socket pathname
...
The size of sun_path has intentionally been left undefined. This is
because different implementations use different sizes. For example,
4.3 BSD uses a size of 108, and 4.4 BSD uses a size of 104. Since
most implementations originate from BSD versions, the size is
typically in the range 92 to 108.
Applications should not assume a particular length for sun_path or
assume that it can hold {_POSIX_PATH_MAX} characters (255).
hence, it seems to me that python should not actually be doing any size
checks on the path passed to getsockaddrarg(). instead is should
dynamically allocate a sockaddr_un large enough to hold whatever string
was pass in. this structure can then be passed on to system calls which
can they check if the specified path is of a supported length. (if you
look at the posix definitions for bind() and connect() you'll see that
they both can return ENAMETOOLONG if the passed in pathname is too
large.)
--
components: None
messages: 106929
nosy: Edward.Pilatowicz
priority: normal
severity: normal
status: open
title: socketmodule.c`getsockaddrarg() should not check the length of sun_path
type: behavior
versions: Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8882
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
