The `G_FILE_CREATE_REPLACE_DESTINATION` flag is equivalent to unlinking
the destination file and re-creating it from scratch. That did
previously work, but in the process the code would call `open(O_CREAT)`
on the file. If the file was a dangling symlink, this would create the
destination file (empty). That’s not an intended side-effect, and has
security implications if the symlink is controlled by a lower-privileged
process.
Fix that by not opening the destination file if it’s a symlink, and
adjusting the rest of the code to cope with
- the fact that `fd == -1` is not an error iff `is_symlink` is true,
- and that `original_stat` will contain the `lstat()` results for the
symlink now, rather than the `stat()` results for its target (again,
iff `is_symlink` is true).
This means that the target of the dangling symlink is no longer created,
which was the bug. The symlink itself continues to be replaced (as
before) with the new file — this is the intended behaviour of
`g_file_replace()`.
The behaviour for non-symlink cases, or cases where the symlink was not
dangling, should be unchanged.
Includes a unit test.
Resolves CVE-2021-28153 (glib#2325). Backported to GLib 2.58 by
Simon McVittie.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
(cherry-picked from commit 317b3b5870)
[Backport to 2.58.x: replace g_local_file_fstat with fstat]
[Backport to 2.58.x: replace g_local_file_lstat with lstat]
[Backport to 2.58.x: replace _g_stat_mode with direct access to st_mode]
[Backport to 2.58.x: don't call g_test_summary()]
Signed-off-by: Simon McVittie <smcv@collabora.com>
4e64a27f4f