bin/181309: gzip can leave corrupt files lingering around a filesystem in the event that a signal != SIGINT was received or the program exited in before completeing the file_compress function

[Garrett Cooper]

>Number:         181309
>Category:       bin
>Synopsis:       gzip can leave corrupt files lingering around a filesystem in the event that a signal != SIGINT was received or the program exited in before completeing the file_compress function
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Aug 14 21:20:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator:     Garrett Cooper
>Release:        10-CURRENT
>Organization:
EMC Isilon
>Environment:
FreeBSD gran-tourismo.west.isilon.com 10.0-CURRENT FreeBSD 10.0-CURRENT #8 bc57ffb: Fri Aug  2 15:14:32 PDT 2013     root@:/usr/obj/usr/src/sys/GRAN-TOURISMO  amd64
>Description:
We have a number of bugs filed for newsyslog compression failure issues open at work due to panics at the time of log rotation, and the like. I did some code inspection and I realized that there are some design flaws with gzip(1). In particular:

1. gzip doesn't use mkstemp and it really should (not using mkstemp means that multiple accesses to the same file can create corrupt gzip files potentially or result in unexpected behavior). renames of the gzip'ed content to a temporary file are guaranteed to be more atomic than writing out to the file itself.
2. It's assumed that if the file_compress function will run to completion, and in which case files can be deleted (which is indeed not the case with some of the code paths in gz_compress that call maybe_err*).
>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted: