Revised fix for CVE-2013-6435

In case of hardlinked files, we first create a zero-length file
to which all the links are created, the content comes in the last
link. When the links have been created with no permissions at all
(as per commit 7e26e2bd726f48836be289400c7d82cb8b067dc1), reopening
the final file for writing the actual content fails for non-root users.
Which breaks installation of hardlinked files for regular users,
including our testsuite.

Creating the files with write-only permissions solves the issue - we
*are* writing to these files afterall so it only makes sense.
This doesn't stop root from reading the file but neither does zero
permissions so no change there. But if somebody reads a file with
write-only permissions and gets garbage, at least we get to tell
them "told you so".

(cherry picked from commit 6e7c6d1a18aa14fc7a980c43d980a26d82f785c4)

1 files changed, 2 insertions, 2 deletions

diff --git a/lib/fsm.c b/lib/fsm.c
index 5b6449c72..d18e4d8b5 100644
--- a/lib/fsm.c
+++ b/lib/fsm.c
@@ -215,9 +215,9 @@ static int expandRegular(rpmfi fi, const char *dest, rpmpsm psm, int nodigest, i
     FD_t wfd = NULL;
     int rc = 0;
 
-    /* Create the file with 000 permissions. */
+    /* Create the file with 0200 permissions (write by owner). */
     {
-	mode_t old_umask = umask(0777);
+	mode_t old_umask = umask(0577);
 	wfd = Fopen(dest, "w.ufdio");
 	umask(old_umask);
     }