[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Michael Felt added the comment: On 16/08/2018 17:34, Ronald Oussoren wrote: > Ronald Oussoren added the comment: > > I don't understand this clarification: > >> Clarification: while Mac/OS falls under "posix" in python terms - maybe >> "breakage" will need to be accepted, >> or, for "back-port

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Ronald Oussoren added the comment: I don't understand this clarification: > Clarification: while Mac/OS falls under "posix" in python terms - maybe > "breakage" will need to be accepted, > or, for "back-ports" Mac/OS will be "as if root or super-user" and use > an additional (optional) argumen

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Michael Felt added the comment: I want to believe this can be resolved - without breakage on POSIX. Clarification: while Mac/OS falls under "posix" in python terms - maybe "breakage" will need to be accepted, or, for "back-ports" Mac/OS will be "as if root or super-user" and use an additional (

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Michael Felt added the comment: my bad: forgot the snippet I mentioned in the previous post: try: lookup("chmod")(dst, mode, follow_symlinks=follow) except NotImplementedError: # if we got a NotImplementedError, it's because # * follow_symlinks=False,

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Michael Felt added the comment: I am looking at this. Based on the comments from a historical perspective - copyfile() needs to be calling the copy_mode function before any copying actually occurs. As the dest is already open for writing it does not matter (on posix) what mode it has later o

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Jim Jewett added the comment: My current UI shows this as relevant *only* to 3.4 and 3.5. If it really has been fixed in 3.6, and the fix can't be backported, I think the risk of breaking backup programs is enough to argue for doing nothing more than a doc change. Anyone still using 3.4 (o

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Change by Giampaolo Rodola' : -- nosy: +giampaolo.rodola ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Larry Hastings added the comment: I'll accept this into 3.4 and 3.5, if someone produces a PR and someone else reviews it. Given that the issue has already celebrated its fifth birthday I can't say I feel a lot of urgency about it. -- ___ Python

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Terry J. Reedy added the comment: Should the patch be turned into a PR or should this be closed? -- nosy: +terry.reedy versions: -Python 3.2, Python 3.3 ___ Python tracker __

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Serhiy Storchaka added the comment: See also issue15795. It would be good to make shutil, zipfile and tarfile interfaces consistent. I think we need more graduated interface matching coretools. """ --preserve[=ATTR_LIST] preserve the specified attributes (default: mode,own

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Christian Heimes added the comment: > Shouldn't you try to make the permission removal atomic? Otherwise there's a > window of opportunity to exploit the suid bit. Permissions bits are copied from the source file *after* all data has been copied to the destination file. copy() calls copyfile()

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Benjamin Peterson added the comment: Not blocking 2.7.4 as discussed on mailing list. -- priority: release blocker -> critical ___ Python tracker ___

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Charles-François Natali added the comment: > Shouldn't you try to make the permission removal atomic? > Otherwise there's a window of opportunity to exploit the suid bit. Actually there's already a race even without setuid bit: http://bugs.python.org/issue15100 All metadat should be set atomic

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Antoine Pitrou added the comment: Shouldn't you try to make the permission removal atomic? Otherwise there's a window of opportunity to exploit the suid bit. -- nosy: +pitrou ___ Python tracker ___

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Hynek Schlawack added the comment: SGTM. I’d like an explicit warning on the security implications in the docs though. -- ___ Python tracker ___

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Christian Heimes added the comment: Here is a new patch with a new keyword argument preserve_sbits. Perhaps we use `True` as default for Python 2.6 to 3.3 and switch to False in Python 3.4? -- Added file: http://bugs.python.org/file29058/17180_preserve_sbits.patch _

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Hynek Schlawack added the comment: Yeah, I’m thinking about backup scripts etc. -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Christian Heimes added the comment: Sorry for the extra noise. I got into a comment conflict with Hynek. Hynek, I don't think it's going to break lots of apps. setuid/setgid programs are rare these days. Most operating system ignore sticky bits on files, too. It may break system scripts that c

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Changes by Christian Heimes : -- keywords: +patch Added file: http://bugs.python.org/file29057/17180.patch ___ Python tracker ___ ___

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Christian Heimes added the comment: Here is a patch for the issue with test and doc updates. I'm escalating the bug to release blocker to draw the attention of our RMs. -- ___ Python tracker __

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Hynek Schlawack added the comment: While I agree that it’s a problem, I’m a bit uneasy about changing that back to 2.7. I’m pretty sure this would break numerous programs. -- ___ Python tracker ___

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Christian Heimes added the comment: cp removes three bits unless preserve ownership is enabled and some additional things are true. mode &= ~ (S_ISUID | S_ISGID | S_ISVTX) S_ISVTX is the sticky bit. -- ___ Python tracker

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Christian Heimes added the comment: Thanks for the report. I agree with your analysis. We should follow the behavior of cp and always strip off the suid/sgid bits in shutil.copy(). coreutil's cp removes the bits and doesn't handle source owner = destination owner special. There are other bits

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

Changes by Antoine Pitrou : -- nosy: +christian.heimes, hynek, tarek priority: normal -> high type: -> security versions: +Python 3.3, Python 3.4 -Python 2.6, Python 3.1 ___ Python tracker

[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits

New submission from Milko Krachounov: When copying the mode of a file with copy, copy2, copymode, copystat or copytree, all permission bits are copied (including setuid and setgit), but the owner of the file is not. This can be used for privilege escalation. An example: -rwSr--r-- 1 milko mi