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

mailbox.mbox.flush() loses mailbox owner #117467

Closed
softins opened this issue Apr 2, 2024 · 3 comments · Fixed by #117510
Closed

mailbox.mbox.flush() loses mailbox owner #117467

softins opened this issue Apr 2, 2024 · 3 comments · Fixed by #117510
Labels
3.12 bugs and security fixes 3.13 new features, bugs and security fixes topic-email type-bug An unexpected behavior, bug, or error

Comments

@softins
Copy link
Contributor

softins commented Apr 2, 2024

In the flush() method for mbox mailboxes, after writing the new file, it correctly copies the file modes from the old file to the new one:

cpython/Lib/mailbox.py

Lines 753 to 755 in 027fa2e

# Make sure the new file's mode is the same as the old file's
mode = os.stat(self._path).st_mode
os.chmod(new_file.name, mode)

However, it doesn't copy the user.group ownership of the old file to the new one, and I think it should.

I implemented a python program to modify a mailbox, in this case to delete old messages from a spam folder. The program runs as root, so that it can operate on folders belonging to different users without having to suid to each user. I found that on flushing after any changes, the mailbox was owned by root.root instead of by its original owner.

Suggest the following code instead:

        # Make sure the new file's mode and owner are the same as the old file's
        info = os.stat(self._path)
        os.chmod(new_file.name, info.st_mode)
        try:
                os.chown(new_file.name, info.st_uid, info.st_gid)
        except OSError:
                pass

Linked PRs

@serhiy-storchaka
Copy link
Member

The suggestion LGTM. Do you mind to create a PR, @softins?

@serhiy-storchaka serhiy-storchaka added 3.12 bugs and security fixes 3.13 new features, bugs and security fixes type-bug An unexpected behavior, bug, or error topic-email labels Apr 3, 2024
@softins
Copy link
Contributor Author

softins commented Apr 3, 2024

The suggestion LGTM. Do you mind to create a PR, @softins?

Sure, will do. I think I will actually change except OSError: to a general except:, in case of other exceptions such as os.chown() not being present on a particular platform.

@serhiy-storchaka
Copy link
Member

serhiy-storchaka commented Apr 3, 2024

Silently ignoring arbitrary exceptions is never a good idea. KeyboardInterrupt, MemoryError and RecursionError can be raised by virtually any code.

It is better to make the exception check more specific, for example: (PermissionError, AttributeError).

softins added a commit to softins/cpython that referenced this issue Apr 3, 2024
serhiy-storchaka added a commit that referenced this issue Apr 4, 2024
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Apr 4, 2024
…17510)

(cherry picked from commit 3f5bcc8)

Co-authored-by: Tony Mountifield <tony@mountifield.org>
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
serhiy-storchaka added a commit that referenced this issue Apr 4, 2024
GH-117537)

(cherry picked from commit 3f5bcc8)

Co-authored-by: Tony Mountifield <tony@mountifield.org>
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
diegorusso pushed a commit to diegorusso/cpython that referenced this issue Apr 17, 2024
…17510)

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.12 bugs and security fixes 3.13 new features, bugs and security fixes topic-email type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants