https://sourceware.org/bugzilla/show_bug.cgi?id=26945
--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> --- It's not that smart_rename should open it and use fchown+fchmod on the result; indeed as you figured that has the same race. The problem is that you threw away the only safe way to perform modifications on the temp file you just created: the fd returned by mkstemp. In addition to the source and dest names, smart_rename needs to take the already-open file descriptors for source and dest that were used for the objcopy (or whatever) operation. Note: I missed this in the original report, but it's also important to use fstat on the file that will be replaced, rather than lstat on the pathname, to ensure the permissions that will be set on the new file are the ones of the file that was processed, and not some other file that was substituted in its place. Failure to do this right may not be exploitable, since the hard link count is checked, but it's still possibly erroneous. -- You are receiving this mail because: You are on the CC list for the bug.
