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

The os module should unset() environment variable at exit #83576

Closed
vstinner opened this issue Jan 20, 2020 · 10 comments
Closed

The os module should unset() environment variable at exit #83576

vstinner opened this issue Jan 20, 2020 · 10 comments
Labels
3.9 only security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@vstinner
Copy link
Member

BPO 39395
Nosy @vstinner, @ericsnowcurrently, @serhiy-storchaka
PRs
  • bpo-39395: Clear env vars set by Python at exit #18078
  • bpo-39395: os.putenv() is now always available #18135
  • 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 2020-01-24.13:12:45.258>
    created_at = <Date 2020-01-20.11:58:54.480>
    labels = ['interpreter-core', '3.9', 'type-crash']
    title = 'The os module should unset() environment variable at exit'
    updated_at = <Date 2020-01-24.20:35:09.542>
    user = 'https://github.com/vstinner'

    bugs.python.org fields:

    activity = <Date 2020-01-24.20:35:09.542>
    actor = 'eric.snow'
    assignee = 'none'
    closed = True
    closed_date = <Date 2020-01-24.13:12:45.258>
    closer = 'vstinner'
    components = ['Interpreter Core']
    creation = <Date 2020-01-20.11:58:54.480>
    creator = 'vstinner'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 39395
    keywords = ['patch']
    message_count = 10.0
    messages = ['360309', '360368', '360369', '360471', '360472', '360515', '360530', '360614', '360615', '360654']
    nosy_count = 3.0
    nosy_names = ['vstinner', 'eric.snow', 'serhiy.storchaka']
    pr_nums = ['18078', '18135']
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'crash'
    url = 'https://bugs.python.org/issue39395'
    versions = ['Python 3.9']

    @vstinner
    Copy link
    Member Author

    os.environ[key] = value has to keep internally the string "key=value\0" after putenv("key=value\0") has been called, since the glibc doesn't copy the string. Python has to manage the string memory.

    Internally, the posix module uses a "posix_putenv_garbage" dictionary mapping key (bytes) to value (bytes). Values are "key=value\0" strings.

    The bpo-35381 issue converted the os ("posix" in practice) module PEP-384: "Remove all static state from posixmodule": commit b396663. The _posix_clear() function is now called by _PyImport_Cleanup().

    Problem: the glibc is not aware that Python is exiting and that the memory of the environment variable has been released. Next access to environment variables ("environ" C variable, putenv, setenv, unsetenv, ...) can crash. Sometimes, it doesn't crash even if the memory has been released, because free() does not always dig immediately holes in the heap memory (the complex problelm of memory fragmentation).

    The posix module should notify the glibc that the memory will be released before releasing the memory, to avoid keeping dangling pointers in the "environ" C variable.

    The following crash in the Elements module is an example of crash introduced by commit b396663 which introduced this issue:
    https://bugzilla.redhat.com/show_bug.cgi?id=1791761

    @vstinner vstinner added 3.9 only security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) labels Jan 20, 2020
    @vstinner
    Copy link
    Member Author

    Fedora downstream issue, crash in the "elements" package: https://bugzilla.redhat.com/show_bug.cgi?id=1791761

    @vstinner
    Copy link
    Member Author

    I proposed bpo-39406 which avoids to have to clear environment variables set by Python at exit on platforms providing setenv().

    @serhiy-storchaka serhiy-storchaka added 3.7 (EOL) end of life 3.8 only security fixes type-crash A hard crash of the interpreter, possibly with a core dump labels Jan 22, 2020
    @serhiy-storchaka
    Copy link
    Member

    bpo-39406 is a new feature. In any case we should fix potential crash in older Python versions.

    @vstinner
    Copy link
    Member Author

    bpo-39406 is a new feature. In any case we should fix potential crash in older Python versions.

    Python 3.8 and older are not affected by this issue since they never destroy the posix_putenv_garbage dictionary: memory is never released.

    @vstinner vstinner removed 3.7 (EOL) end of life 3.8 only security fixes labels Jan 22, 2020
    @vstinner
    Copy link
    Member Author

    I closed bpo-39406: os.putenv() is now implemented with setenv() if available. The internal putenv_dict is no longer used on Windows and if setenv() is available.

    Now only non-Windows platforms without setenv() are affected by this issue.

    @vstinner
    Copy link
    Member Author

    Clearing environment variables at exit has a drawback: it changes the behavior in code executed after Python finalization (Py_FinalizeEx() call). It may cause regression.

    So I proposed PR 18135 to fix this issue differently: on non-Windows platforms, Python now requires setenv() to build. This PR has no backward compatibility issue: it doesn't unset environment variables at exit.

    @vstinner
    Copy link
    Member Author

    New changeset b8d1262 by Victor Stinner in branch 'master':
    bpo-39395: putenv() and unsetenv() always available (GH-18135)
    b8d1262

    @vstinner
    Copy link
    Member Author

    On non-Windows platforms, Python now requires setenv() and unsetenv()
    functions to build.

    setenv() and unsetenv() should be available on all platforms supported by Python. If it's not the case, someone can maintain a downstream patch which is a revert of commit b8d1262.

    If someone asks to support a platform which doesn't provide setenv() and unsetenv(), we can revisit the idea of unsetting variables set by Python at exit, to workaround putenv() issue: something like my (abandonned) PR 18078.

    @ericsnowcurrently
    Copy link
    Member

    FTR, bpo-39376 is related (avoid the process-global env vars in the first place).

    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    3.9 only security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) type-crash A hard crash of the interpreter, possibly with a core dump
    Projects
    None yet
    Development

    No branches or pull requests

    3 participants