rofiles-fuse: Support breaking hardlinks to fs-verity files

[alexlarsson]

In case fs-verity is in used for the repo objects, and something like "rpm-ostree apply-live" uses rofiles-fuse with --copyup, then writing to a hard-linked file fails to copy up, like this:

echo foo > /a/rofile-mnt/a-file
/a/rofile-mnt/a-file: Operation not permitted

The reason for this is that do_write() starts by opening the file non-truncating for writing, stat:ing it and then calling verify_write_or_copyup(). It is expecting the the open(write) to succeed, however, in the fs-verity case any open with write fails with EPERM.

We fix this by delaying the EPERM failure, only reporting it when the file descriptor needs to be used. In the case this triggered a copyup the file descriptor will be reopened, and in this case we will not get the EPERM anymore.

To simplify this code the fd variable now uses glnx_autofd.

This fixes coreos/rpm-ostree#4827

[cgwalters]

Looks sane, would be good to have a new test case...I was looking at this but the existing test case is failing for me with

PASS: tests/test-rofiles-fuse.sh 10 flock
++ stat -c %i checkout-test2/firstfile
+ firstfile_orig_inode=98938420
+ echo -n truncating
/var/srv/walters/src/github/ostreedev/ostree/tests/test-rofiles-fuse.sh: line 157: mnt/firstfile: Input/output error
++ report_err
++ local exit_status=1
Unexpected nonzero exit status 1 while running: echo -n truncating > mnt/firstfile

which I haven't debugged yet.

Just thinking about this though...I bet we could test your change here even if the host environment doesn't use fsverity by simply using chmod 0 on a file - (and dropping CAP_DAC_OVERRIDE if we happen to have it, but the unit tests are intended to run as non-root anyways).

[alexlarsson]

I'll have a look at adding a test tomorrow

[alexlarsson]

Not sure chmod is enough, that would give a EACCESS instead of EPERM, no? Maybe some immutable attr would workj?

[cgwalters]

One problem here is that we do copyup if the calling process just does e.g. chmod too, and we're not handling that here.

[cgwalters]

Ended up trying out an alternative flow in #3175 - mind taking a look?

[alexlarsson]

The other approach seems fine to me too.