Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

socket: AF_UNIX socket paths not handled according to PEP 383 #52620

Closed
baikie mannequin opened this issue Apr 11, 2010 · 6 comments
Closed

socket: AF_UNIX socket paths not handled according to PEP 383 #52620

baikie mannequin opened this issue Apr 11, 2010 · 6 comments
Labels
extension-modules C modules in the Modules dir type-bug An unexpected behavior, bug, or error

Comments

@baikie
Copy link
Mannequin

baikie mannequin commented Apr 11, 2010

BPO 8373
Nosy @loewis, @pitrou, @vstinner
Files
  • af_unix-pep383.diff: Handle AF_UNIX addresses according to PEP 383
  • af_unix-pep383-no-8372-fix.diff: Version which applies onto existing code, without fixing issue python/issues-test-cpython#8372
  • test-existing.diff: Tests for existing behaviour that patch preserves
  • test-new.diff: Tests for new behaviour (surrogateescape handling)
  • af_unix-pep383-doc.diff: Doc updates
  • af_unix-pep383-docs-tests-3.2.diff: Documentation and tests for new version of patch
  • af_unix-pep383-3.2-with-linux-unterminated.diff: Patch for 3.2 (if linux-pass-unterminated patch from issue python/issues-test-cpython#8372 is applied)
  • af_unix-pep383-3.2-without-linux-unterminated.diff: Patch for 3.2 (if linux-pass-unterminated patch is not applied)
  • af_unix-pep383-docs-tests-3.2-2.diff: Removed use of sys.setfilesystemencoding()
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
    closed_at = <Date 2011-12-16.13:47:41.337>
    created_at = <Date 2010-04-11.18:45:26.846>
    labels = ['extension-modules', 'type-bug']
    title = 'socket: AF_UNIX socket paths not handled according to PEP 383'
    updated_at = <Date 2011-12-16.13:47:41.334>
    user = 'https://bugs.python.org/baikie'

    bugs.python.org fields:

    activity = <Date 2011-12-16.13:47:41.334>
    actor = 'pitrou'
    assignee = 'none'
    closed = True
    closed_date = <Date 2011-12-16.13:47:41.337>
    closer = 'pitrou'
    components = ['Extension Modules']
    creation = <Date 2010-04-11.18:45:26.846>
    creator = 'baikie'
    dependencies = []
    files = ['16881', '16882', '16883', '16884', '16885', '18850', '18851', '18852', '18853']
    hgrepos = []
    issue_num = 8373
    keywords = ['patch']
    message_count = 6.0
    messages = ['102865', '102866', '116111', '116116', '149621', '149622']
    nosy_count = 5.0
    nosy_names = ['loewis', 'pitrou', 'vstinner', 'baikie', 'python-dev']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue8373'
    versions = ['Python 3.3']

    @baikie
    Copy link
    Mannequin Author

    baikie mannequin commented Apr 11, 2010

    In 3.x, the socket module assumes that AF_UNIX addresses use
    UTF-8 encoding - this means, for example, that accept() will
    raise UnicodeDecodeError if the peer socket path is not valid
    UTF-8, which could crash an unwary server.

    Python 3.1.2 (r312:79147, Mar 23 2010, 19:02:21) 
    [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu4)] on linux2
    Type "help", "copyright", "credits" or "license" for more
    information.
    >>> from socket import *
    >>> s = socket(AF_UNIX, SOCK_STREAM)
    >>> s.bind(b"\xff")
    >>> s.getsockname()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 0: unexpected code byte

    I'm attaching a patch to handle socket paths according to PEP-383. Normally this would use PyUnicode_FSConverter, but there
    are a couple of ways in which the address handling currently
    differs from normal filename handling.

    One is that embedded null bytes are passed through to the system
    instead of being rejected, which is needed for the Linux abstract
    namespace. These abstract addresses are returned as bytes
    objects, but they can currently be specified as strings with
    embedded null characters as well. The patch preserves this
    behaviour.

    The current code also accepts read-only buffer objects (it uses
    the "s#" format), so in order to accept these as well as
    bytearray filenames (which the posix module accepts), the patch
    simply accepts any single-segment buffer, read-only or not.

    This patch applies on top of the patches I submitted for issue
    bpo-8372 (rather than knowingly running past the end of sun_path).

    @baikie baikie mannequin added extension-modules C modules in the Modules dir type-bug An unexpected behavior, bug, or error labels Apr 11, 2010
    @baikie
    Copy link
    Mannequin Author

    baikie mannequin commented Apr 11, 2010

    This patch does the same thing without fixing issue bpo-8372 (not
    that I'd recommend that, but it may be easier to review).

    @baikie
    Copy link
    Mannequin Author

    baikie mannequin commented Sep 11, 2010

    Updated the patches for Python 3.2 - these are now simpler as
    they do not support bytearray arguments, as these are no longer
    used for filenames (the existing code does not support bytearrays
    either).

    I've put the docs and tests in one patch, and made separate
    patches for the code, one for if the linux-pass-unterminated
    patch from issue bpo-8372 is applied, and one for if it isn't.

    One point I neglected to comment on before is the ability to
    specify an address in the Linux abstract namespace as a
    filesystem-encoded string prefixed with a null character. This
    may seem strange, but as well as simplifying the code, it does
    support an actual use case, as on Linux systems the abstract
    namespace is sometimes used to hold names based on real
    filesystem paths such as "\x00/var/run/hald/dbus-XAbemUfDyQ", or
    imaginary ones, such as "\x00/com/ubuntu/upstart". In fact,
    running "netstat" on my own system did not reveal any non-textual
    abstract names in use (although they are of course allowed).

    @baikie
    Copy link
    Mannequin Author

    baikie mannequin commented Sep 11, 2010

    One of the tests got broken by the removal of sys.setfilesystemencoding(). Replaced it.

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Dec 16, 2011

    New changeset 1f23bb74f4bc by Antoine Pitrou in branch 'default':
    Issue bpo-8373: The filesystem path of AF_UNIX sockets now uses the filesystem
    http://hg.python.org/cpython/rev/1f23bb74f4bc

    @pitrou
    Copy link
    Member

    pitrou commented Dec 16, 2011

    Patch committed in 3.3 (default branch), thank you!

    @pitrou pitrou closed this as completed Dec 16, 2011
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    extension-modules C modules in the Modules dir type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Development

    No branches or pull requests

    1 participant