rofiles-fuse: also pass mode for O_RDONLY

In the `O_RDONLY` case, we were calling `openat` without a mode
argument. However, it's perfectly legal (albeit unusual) to do
`open(O_RDONLY|O_CREAT)`. One such application that makes use of this is
`flock(1)`.

This was actually caught by `_FORTIFY_SOURCE=2`, and once we run
`rofiles-fuse` with `-f`, the message is clear:

```
*** invalid openat64 call: O_CREAT or O_TMPFILE without mode ***:
rofiles-fuse terminated
======= Backtrace: =========
/lib64/libc.so.6(+0x7c8dc)[0x7f36d9f188dc]
/lib64/libc.so.6(__fortify_fail+0x37)[0x7f36d9fbfaa7]
/lib64/libc.so.6(+0x10019a)[0x7f36d9f9c19a]
rofiles-fuse[0x401768]
...
```

Without `_FORTIFY_SOURCE`, the file gets created, but its mode is
completely random.

I ran into this while investigating
https://github.com/projectatomic/rpm-ostree/pull/1003.

Closes: #1200
Approved by: cgwalters

1 files changed, 4 insertions, 1 deletions

diff --git a/tests/test-rofiles-fuse.sh b/tests/test-rofiles-fuse.sh
index d329d765..6222929e 100755
--- a/tests/test-rofiles-fuse.sh
+++ b/tests/test-rofiles-fuse.sh
@@ -26,7 +26,7 @@ skip_without_user_xattrs
 
 setup_test_repository "bare"
 
-echo "1..7"
+echo "1..8"
 
 cd ${test_tmpdir}
 mkdir mnt
@@ -114,3 +114,6 @@ fi
 assert_file_has_content err.txt "Unable to do hardlink checkout across devices"
 
 echo "ok checkout copy fallback"
+
+# check that O_RDONLY|O_CREAT is handled correctly; used by flock(1) at least
+flock mnt/nonexistent-file echo "ok create file in ro mode"