This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: os.set_inheritable(): fall back to fcntl() if ioctl() fails with EACCES
Type: behavior Stage:
Components: Versions: Python 3.6, Python 3.5
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Michał Bednarski, python-dev, vstinner
Priority: normal Keywords: patch

Created on 2016-05-19 12:15 by Michał Bednarski, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
set_inheritable-eacces.diff Michał Bednarski, 2016-05-19 12:15 Patch for treating EACCES same as ENOTTY in set_inheritable() review
set_inheritable-eacces.diff Michał Bednarski, 2016-05-19 14:01 Patch for treating EACCES same as ENOTTY in set_inheritable() review
Messages (7)
msg265853 - (view) Author: Michał Bednarski (Michał Bednarski) * Date: 2016-05-19 12:15
When SELinux forbids ioctl() it fails with EACCES and whole os.set_inheritable raises exception.

As in https://bugs.python.org/issue22258 code was added to fall back to fcntl when ioctl() fails with ENOTTY I'm adding EACCES value to same condition to fall back to fcntl().
msg265854 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2016-05-19 12:54
Hum, I'm surprised that SELinux blocks such safe function. Maybe the SELinux policy should be completed to allow it?

Detect when ioctl() fails with EACCESS and fallback to fnctl() sounds like a good option. But do you expect ioctl() to always fail with EACCESS? Or only fail sometimes, or only on some file descriptors? Your patch remembers that ioctl() fails once and never retries.

About your patch: please add a comment explaining why you fallback with a reference to this issue ("Issue #27057").
msg265860 - (view) Author: Michał Bednarski (Michał Bednarski) * Date: 2016-05-19 14:01
> Hum, I'm surprised that SELinux blocks such safe function. Maybe the SELinux policy should be completed to allow it?
The ioctl is blocked for given file type regardless of request argument. As I'm running Python on non-rooted Android updating policy is not really an option.

> But do you expect ioctl() to always fail with EACCESS? Or only fail sometimes, or only on some file descriptors? Your patch remembers that ioctl() fails once and never retries.
It will always fail for given file type (such as sockets), while it will work for others (such as regular files). I think that remembering that ioctl doesn't work may be okay, though I may be wrong. Either way if we are wrong whenever ioctl works we'll do one extra syscall.

> About your patch: please add a comment explaining why you fallback with a reference to this issue ("Issue #27057").
Attached
msg265863 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-05-19 14:50
New changeset 13c5135d8467 by Victor Stinner in branch '3.5':
Fix os.set_inheritable() on Android
https://hg.python.org/cpython/rev/13c5135d8467

New changeset 783c1b8cdddb by Victor Stinner in branch 'default':
Merge 3.5 (issue #27057)
https://hg.python.org/cpython/rev/783c1b8cdddb
msg265864 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2016-05-19 14:52
> The ioctl is blocked for given file type regardless of request argument. As I'm running Python on non-rooted Android updating policy is not really an option.

Oh. Right :-) My intent was to suggest to report the SELinux issue upstream ;-)

> It will always fail for given file type (such as sockets), while it will work for others (such as regular files). I think that remembering that ioctl doesn't work may be okay, though I may be wrong. Either way if we are wrong whenever ioctl works we'll do one extra syscall.

The purpose of using ioctl() is to *reduce* the number of syscalls. If an application mostly use sockets, it will do 3 syscalls per socket (ioctl, fcntl get, fcntl set) instead of just 2 (fcntl get, fcntl set) :-/ So I like your patch ;-)

I applied your fix to Python 3.5 and 3.6. Thanks for your contribution.

You should now sign the PSF Contributor Agreement:
https://www.python.org/psf/contrib/contrib-form/

(Well, in fact it would be better to do that *before* merging your change, but well, your change is short enough ;-))
msg265869 - (view) Author: Michał Bednarski (Michał Bednarski) * Date: 2016-05-19 15:17
> You should now sign the PSF Contributor Agreement
Done.

> (Well, in fact it would be better to do that *before* merging your change, but well, your change is short enough ;-))
Well on https://docs.python.org/devguide/patch.html was said "For non-trivial changes".
msg265872 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2016-05-19 16:16
>> You should now sign the PSF Contributor Agreement
>Done.

Thanks!
History
Date User Action Args
2022-04-11 14:58:31adminsetgithub: 71244
2016-05-19 16:16:03vstinnersetmessages: + msg265872
2016-05-19 15:17:00Michał Bednarskisetmessages: + msg265869
2016-05-19 14:52:45vstinnersetstatus: open -> closed
resolution: fixed
messages: + msg265864

versions: + Python 3.5
2016-05-19 14:50:04python-devsetnosy: + python-dev
messages: + msg265863
2016-05-19 14:01:33Michał Bednarskisetfiles: + set_inheritable-eacces.diff

messages: + msg265860
2016-05-19 12:54:28vstinnersetnosy: + vstinner
messages: + msg265854
2016-05-19 12:15:56Michał Bednarskicreate