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.

Author christian.heimes
Recipients Arfrever, benjamin.peterson, christian.heimes, georg.brandl, hynek, larry, milko.krachounov, neologix, pitrou, tarek
Date 2013-06-19.14:43:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1371653039.95.0.800199447912.issue17180@psf.upfronthosting.co.za>
In-reply-to
Content
> 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() followed by copymode()

copyfile() doesn't create files with SUID. In fact it has 0666 & umask. In worst case the new file is readable and writable by every user. The new patch addresses the unlikely issue with os.open()ing the file with mask=0600.

I could also add a create_mode argument to _io.FileIO() in order to make the permission bits of new files more flexible. Modules/_io/fileio.c hard codes mode as 0600.
History
Date User Action Args
2013-06-19 14:44:00christian.heimessetrecipients: + christian.heimes, georg.brandl, pitrou, larry, benjamin.peterson, tarek, Arfrever, milko.krachounov, neologix, hynek
2013-06-19 14:43:59christian.heimessetmessageid: <1371653039.95.0.800199447912.issue17180@psf.upfronthosting.co.za>
2013-06-19 14:43:59christian.heimeslinkissue17180 messages
2013-06-19 14:43:59christian.heimescreate