[issue28134] socket.socket(fileno=fd) does not work as documented

Christian Heimes added the comment: Yes, the fix works well enough. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue28134] socket.socket(fileno=fd) does not work as documented

Nathaniel Smith added the comment: Am I right that this is considered fixed (or at least as fixed as it can be), and the issue should be closed? Also, small note in case anyone stumbles across this in the future and is confused: Python does *not* handle this correctly on Windows. I suspect

[issue28134] socket.socket(fileno=fd) does not work as documented

YoSTEALTH added the comment: It would be nice if "python" accounted for such low level os things. None the less client.detach() method works fine. I really did enjoy your talk, kinda bummed it was short and didn't get into more details. Thanks for your help and

[issue28134] socket.socket(fileno=fd) does not work as documented

Christian Heimes added the comment: File descriptors are a advanced features and expose low level operating system resources. You really have to understand how the OS works. They cannot be reference counted. In fact they *are* the reference to entries in the Kernel's global

[issue28134] socket.socket(fileno=fd) does not work as documented

YoSTEALTH added the comment: Christian thank you for your reply, i really appreciate it. Lets analyze this a bit: - Technically speaking i can "return client" directly and it would NOT close the socket. - Shouldn't "inside" having reference to same fd mean +1 to

[issue28134] socket.socket(fileno=fd) does not work as documented

Christian Heimes added the comment: The problem is fixed and your example behaves as expected. The laddr string is the result of inside.getsockname() and raddr string is the result of inside.getpeername(). In your example, inside and client share the same file descriptor.

[issue28134] socket.socket(fileno=fd) does not work as documented

YoSTEALTH added the comment: I am using 3.7.0b1 i don't think this issue is fixed! # simple mockup: # -- def accept(sock): client, addr = sock.accept() inside = socket(fileno=client.fileno()) print(inside) # <__main__.Socket fd=5,

[issue28134] socket.socket(fileno=fd) does not work as documented

Christian Heimes added the comment: New changeset 2e0ecde8d74f5fc0e3e3e39216975cc70efc4796 by Christian Heimes in branch 'master': bpo-28134: Ignore proto in unknown socket test (GH-5435) https://github.com/python/cpython/commit/2e0ecde8d74f5fc0e3e3e39216975cc70efc4796

[issue28134] socket.socket(fileno=fd) does not work as documented

Change by Christian Heimes : -- pull_requests: +5268 ___ Python tracker ___ ___

[issue28134] socket.socket(fileno=fd) does not work as documented

Christian Heimes added the comment: The test for proto isn't super critical. It's mostly ignored any way. I'll submit a band-aid. -- ___ Python tracker

[issue28134] socket.socket(fileno=fd) does not work as documented

STINNER Victor added the comment: x86-64 Sierra 3.x is grumpy: http://buildbot.python.org/all/#/builders/14/builds/659 == FAIL: test_uknown_socket_family_repr (test.test_socket.GeneralModuleTests)

[issue28134] socket.socket(fileno=fd) does not work as documented

Christian Heimes added the comment: I'm leaving the ticket open to remind me that I have to add a whatsnew entry and maybe consider a backport. -- ___ Python tracker

[issue28134] socket.socket(fileno=fd) does not work as documented

Christian Heimes added the comment: New changeset b6e43af669f61a37a29d8ff0785455108e6bc29d by Christian Heimes in branch 'master': bpo-28134: Auto-detect socket values from file descriptor (#1349)

[issue28134] socket.socket(fileno=fd) does not work as documented

Christian Heimes added the comment: Issue #32454 adds socket.close(fd) function. -- ___ Python tracker ___

[issue28134] socket.socket(fileno=fd) does not work as documented

Christian Heimes added the comment: Yuri, * The patch is purely about Python's view of the socket. The actual behavior of the OS socket fd is not influenced by socket.socket()'s family, type and protocol. However the especially the family is critical for Python because a

[issue28134] socket.socket(fileno=fd) does not work as documented

Yury Selivanov added the comment: Let's quickly iterate over what's possible first: * It's possible to check the type of the FD using "getsockopt(SOL_SOCKET, SO_TYPE)" on all platforms. * It's possible to check family/proto of the FD using "getsockopt(SOL_SOCKET,

[issue28134] socket.socket(fileno=fd) does not work as documented

Changes by Christian Heimes : -- pull_requests: +1461 ___ Python tracker ___ ___

[issue28134] socket.socket(fileno=fd) does not work as documented

Christian Heimes added the comment: Here is another example of how broken and dangerous fileno argument is. getpeername() is neither a valid IPv4 tuple nor a valid IPv6 tuple. It's all messed up: >>> import socket >>> s = socket.create_connection(('www.python.org', 443)) >>> s >>>

[issue28134] socket.socket(fileno=fd) does not work as documented

Changes by Christian Heimes : -- assignee: -> christian.heimes components: +Extension Modules stage: needs patch -> patch review ___ Python tracker

[issue28134] socket.socket(fileno=fd) does not work as documented

Christian Heimes added the comment: I'm well aware that it does not work in all cases. However it works good enough in most cases. Right now the fileno argument must be considered broken because it leads to wrong results. It is a problem and possible security issue for a couple of use cases,

[issue28134] socket.socket(fileno=fd) does not work as documented

Martin Panter added the comment: Personally, I’m not too enthusiastic, because it is rather magical, and does not work in all cases. It seems more like a feature than a bug fix. But I have rarely used the fileno=... parameter, and it shouldn’t have much negative impact, so I’m not too fussed.

[issue28134] socket.socket(fileno=fd) does not work as documented

Christian Heimes added the comment: How about we fix the code and only document the limitations instead? :) After all it works fine on Windows and it is documented to work on all operating systems. Since it's a bug we can fix it in 3.5, too. My patch implements a best-effort to get type,

[issue28134] socket.socket(fileno=fd) does not work as documented

Martin Panter added the comment: I agree the doc is far from perfect. The bit I was going off is just above , saying “these (read-only) attributes that correspond to the values given to the socket constructor”. My instinct

[issue28134] socket.socket(fileno=fd) does not work as documented

Christian Heimes added the comment: Martin, the documentation says "If fileno is specified, the other arguments are ignored, causing the socket with the specified file descriptor to return." It's a direct quote from Python 3's socket library documentation. For a non-native speaker like me,

[issue28134] socket.socket(fileno=fd) does not work as documented

Martin Panter added the comment: The documentation says that the family, type and proto attributes correspond to the constructor arguments. Although it is unfortunate and quirky, I think your behaviour does match the documentation. Do the mismatched settings cause any serious problems with

[issue28134] socket.socket(fileno=fd) does not work as documented

R. David Murray added the comment: See also issue 27377? -- nosy: +r.david.murray ___ Python tracker ___ ___

[issue28134] socket.socket(fileno=fd) does not work as documented

Christian Heimes added the comment: I expected that socket.socket(fileno) would fill in all socket options like my own implementation https://github.com/tiran/socketfromfd/blob/master/socketfromfd.py -- ___ Python tracker

[issue28134] socket.socket(fileno=fd) does not work as documented

Changes by Christian Heimes : -- stage: -> needs patch type: -> behavior ___ Python tracker ___

[issue28134] socket.socket(fileno=fd) does not work as documented

New submission from Christian Heimes: Documentation of socket.socket(fileno) https://docs.python.org/3/library/socket.html#socket.socket says: > If fileno is specified, the other arguments are ignored, causing the socket > with the specified file descriptor to return. The feature does not