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
Origin: upstream, 2017.12, commit:
d4c7093e370843c57eab2f89f0c39ef449e6b32e
Gbp-Pq: Topic 2017.12
Gbp-Pq: Name rofiles-fuse-also-pass-mode-for-O_RDONLY.patch
tests: Reset umask to 022 while creating test repository
In test-basic-root.sh we make assertions about the permissions
of files like baz/cow, which were created without an explicit chmod.
We can't do that unless we control the permissions.
For some reason the "debomatic" autobuilder used to do some Debian
archive rebuilds does the entire build including build-time tests
as uid 0 with umask 002, which broke those assertions. This seems
a weird thing to do, and I've opened a bug, but it also seems
reasonable to fix this test.
This also lets us remove a couple of existing workarounds for the
same issue.
Bug-Debian: https://bugs.debian.org/876138
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #1192
Approved by: cgwalters
Forwarded: https://github.com/ostreedev/ostree/pull/1192
Applied-upstream: 2017.12, commit:
e3c3ec5dd91492e82c79223052443d038c60f41c
Gbp-Pq: Topic 2017.12
Gbp-Pq: Name tests-Reset-umask-to-022-while-creating-test-repository.patch
tests: Explicitly unset LANGUAGE after setting LC_ALL
As a GNU extension, LANGUAGE takes precedence over LC_ALL for
gettext(3) whenever the locale is not C, causing tests that grep for
specific English strings to fail when run in non-English locales.
The upstream glibc proposal for C.UTF-8 would give C.UTF-8 the same
special case as C here, but the implementation in Debian does not
currently have this, so we have to unset LANGUAGE too.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Forwarded: https://github.com/ostreedev/ostree/pull/1188
Applied-upstream: 2017.12, commit:
223c940b46a4bb335665df7436566b73cdf0effd
Gbp-Pq: Topic 2017.12
Gbp-Pq: Name tests-Explicitly-unset-LANGUAGE-after-setting-LC_ALL.patch
tests: Fix JavaScript tests with gjs 1.50.0
In recent gjs, you can't declare a variable with "let" multiple times.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #1178
Approved by: cgwalters
Forwarded: https://github.com/ostreedev/ostree/pull/1178
Applied-upstream: 2017.12, commit:
1b430a776486d68be2d16a0ec53ad5512c604988
Gbp-Pq: Topic 2017.12
Gbp-Pq: Name tests-Fix-JavaScript-tests-with-gjs-1.50.0.patch
projects / ostree.git / log