fchown and fchmod syscalls should return EBADF for file opened via O_PATH flag

[anjalirai-intel]

Description of the problem

The tests contains 5 subset, the file is opened with O_RDWR | O_PATH flag and it is tested with 5 different syscall write, read, fcmod, fchown, fgetxattr

Test for file having O_PATH flag with fchmod and fchown syscalls should also result in failure with error EBADF

1. Read          -> PASS, fails with EBADF
2. write         -> PASS, fails with EBADF
3. fchmod        -> FAIL, it throws EINVAL error
4. fchown        -> SUCCESS, 
5. fgetxattr     -> Currently not supported by Gramine

Steps to reproduce

Compile the open13 test and run with gramine-direct/gramine-sgx, c code and logs has been attached in zip
open13.zip

Expected results

open13 1 TPASS : read(2) failed with EBADF
open13 2 TPASS : write(2) failed with EBADF
open13 3 TPASS : fchmod(2) failed with EBADF
open13 4 TPASS : fchown(2) failed with EBADF
open13 5 TPASS : fgetxattr(2) failed with EBADF

Actual results

[0.006] open13 1 TPASS : read(2) failed with EBADF
[0.006] open13 2 TPASS : write(2) failed with EBADF
[0.006] open13 3 TFAIL : fchmod(2) failed unexpectedly, expected EBADF: TEST_ERRNO=EINVAL(22): Invalid argument
[0.006] open13 4 TFAIL : fchown(2) succeeded unexpectedly
[0.006] open13 5 TFAIL : fgetxattr(2) failed unexpectedly, expected EBADF: TEST_ERRNO=ENOSYS(38): Function not implemented

Gramine commit hash

1cf1f46

[dimakuv]

I confirm that fchmod() and fchown() are not correctly emulated in Gramine on O_PATH-opened file descriptors.

Technically, O_PATH-opened FDs do not have an underlying file to manipulate, so syscalls like fchmod() and fchown() must fail with EBADF. This should be emulated as a corner case in Gramine. This is not done, so Gramine tries to work on these "shallow" FDs as if they are real files, and fails.