[LibOS] Fix ENOENT error in fchown on unlinked file

[dimakuv]

Description of the changes

This is conceptually similar to the commit "[LibOS] Fix ENOENT error in fchmod on unlinked file".

This PR was created while reviewing #1874.

How to test this PR?

Added a sub-test to the rename_unlink LibOS regression test.

If you want to run this sub-test on vanilla Linux, change UID and GID in fchown() to some reasonable IDs available on your system.

---

This change is 

[dimakuv]

Reviewable status: 0 of 2 files reviewed, all discussions resolved, not enough approvals from maintainers (2 more required), not enough approvals from different teams (1 more required, approved so far: Intel)

a discussion (no related file):
FYI: I double checked that vanilla Linux kernel correctly fchown()s the file even after it was unlinked.

---

a discussion (no related file):
This PR is modelled exactly after #1538.

---

---

libos/src/sys/libos_file.c line 242 at r1 (raw file):

    unlock(&hdl->inode->lock);

    ret = 0;

FYI: This is just a random improvement of the related code.

[oshogbo]

Reviewable status: 0 of 2 files reviewed, all discussions resolved, not enough approvals from maintainers (2 more required), not enough approvals from different teams (1 more required, approved so far: Intel)

[g2flyer]

As mentioned in discussion of #1874 i can confirm that this PR fixes the fchown issue identified in #1874 and in more minimal (and complete :-)) ways than #1874. I wonder though whether the new test-vectors from #1874 might be better add directly to this PR rather than in a separate one?

Reviewable status: 0 of 2 files reviewed, all discussions resolved, not enough approvals from maintainers (2 more required), not enough approvals from different teams (1 more required, approved so far: Intel)

[dimakuv]

Done, added your sub-tests too.

I force-pushed since Mariusz finished his review, others didn't start it, and I wanted to not forget to add Michael Steiner as a co-author in the commit message.

Reviewable status: 0 of 2 files reviewed, all discussions resolved, not enough approvals from maintainers (2 more required), not enough approvals from different teams (1 more required, approved so far: Intel)

[mkow]

Reviewed 1 of 2 files at r1, all commit messages.
Reviewable status: 1 of 2 files reviewed, 1 unresolved discussion, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel) (waiting on @dimakuv)

---

libos/test/regression/rename_unlink.c line 230 at r2 (raw file):

        err(1, "create %s", path1);

    if (fchown(fd, /*owner=*/123, /*group=*/123) != 0) /* dummy owner/group just for testing */

This fails when run natively, could you change this test somehow so that it also works natively? It would make it easier to verify whether everything in Gramine works exactly as on Linux.

[g2flyer]

This fails when run natively, could you change this test somehow so that it also works natively? It would make it easier to verify whether everything in Gramine works exactly as on Linux.

In my original version from that did run natively as long as you run it as root (i actually had also a corresponding comment) and i think that is somewhat unavoidable. I've used different ids but i think it still works with 123, the ids do not necessarily have to exist in /etc/passwd et al for it to work.

[mkow]

Reviewable status: 1 of 2 files reviewed, 1 unresolved discussion, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel) (waiting on @dimakuv)

---

libos/test/regression/rename_unlink.c line 230 at r2 (raw file):
@g2flyer: Please reply using Reviewable, so that your reply lands in a proper thread ;)

In my original version from that did run natively as long as you run it as root (i actually had also a corresponding comment) and i think that is somewhat unavoidable. I've used different ids but i think it still works with 123, the ids do not necessarily have to exist in /etc/passwd et al for it to work.

In the future we'd like to run these tests in CI also natively, and that requirement would prevent this. It should be possible to change it, maybe chown() to the current user? (no-op, but should still trigger all the logic).

[g2flyer]

In the future we'd like to run these tests in CI also natively, and that requirement would prevent this. It should be possible to change it, maybe chown() to the current user? (no-op, but should still trigger all the logic).

We don't run CI containerized? Otherwise running as "root" is not really a problem? Using your own id (and essentially not changing the ids) wouldn't really work, e.g., in test_rename_fchown_fchmod to detect all potential issues? In particular, i don't think you would have detected the original bug?

[mkow]

Reviewable status: 1 of 2 files reviewed, 1 unresolved discussion, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel) (waiting on @dimakuv)

---

libos/test/regression/rename_unlink.c line 230 at r2 (raw file):

We don't run CI containerized? Otherwise running as "root" is not really a problem? Using your own id (and essentially not changing the ids) wouldn't really work, e.g., in test_rename_fchown_fchmod to detect all potential issues? In particular, i don't think you would have detected the original bug?

Ah, right, then it should work in CI, it will just be annoying when running the tests manually, outside of CI.
@dimakuv, @woju, @kailun-qin, @oshogbo: what do you think? Especially, is there a better way to implement this test?

@g2flyer: and please again, use Reviewable for comments :) When you comment on GitHub your comments are not linked to the discussion thread and land in a different place, without the context.

[woju]

Reviewable status: 1 of 2 files reviewed, 1 unresolved discussion, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel) (waiting on @dimakuv, @g2flyer, @kailun-qin, and @oshogbo)

---

libos/test/regression/rename_unlink.c line 230 at r2 (raw file):

Previously, mkow (Michał Kowalczyk) wrote…

We don't run CI containerized? Otherwise running as "root" is not really a problem? Using your own id (and essentially not changing the ids) wouldn't really work, e.g., in test_rename_fchown_fchmod to detect all potential issues? In particular, i don't think you would have detected the original bug?

Ah, right, then it should work in CI, it will just be annoying when running the tests manually, outside of CI.
@dimakuv, @woju, @kailun-qin, @oshogbo: what do you think? Especially, is there a better way to implement this test?

@g2flyer: and please again, use Reviewable for comments :) When you comment on GitHub your comments are not linked to the discussion thread and land in a different place, without the context.

If you're non-root (and without CAP_FOWNER), fchmod should succeed if gid matches current euid and that euid (user) is a member of the group that is the param of the operation. So you could make it this way:

1. geteuid()
2. if euid is 0 pick something, maybe 65534:65534 (nobody:nobody)
3. getgroups()
4. if there is only one group and matches the existing file, skip the test,
5. pick first group that does not match the group of the target file,
6. fchown(fd, geteuid(), <group from point 5>).

[woju]

Reviewable status: 1 of 2 files reviewed, 1 unresolved discussion, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel) (waiting on @dimakuv, @g2flyer, @kailun-qin, and @oshogbo)

---

libos/test/regression/rename_unlink.c line 230 at r2 (raw file):

Previously, woju (Wojtek Porczyk) wrote…

If you're non-root (and without CAP_FOWNER), fchmod should succeed if gid matches current euid and that euid (user) is a member of the group that is the param of the operation. So you could make it this way:

1. geteuid()
2. if euid is 0 pick something, maybe 65534:65534 (nobody:nobody)
3. getgroups()
4. if there is only one group and matches the existing file, skip the test,
5. pick first group that does not match the group of the target file,
6. fchown(fd, geteuid(), <group from point 5>).

... if uid matches current euid

[dimakuv]

Reviewable status: 1 of 2 files reviewed, 1 unresolved discussion, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel) (waiting on @g2flyer, @kailun-qin, and @oshogbo)

---

libos/test/regression/rename_unlink.c line 230 at r2 (raw file):

Previously, woju (Wojtek Porczyk) wrote…

... if uid matches current euid

@mkow We already have a bunch of tests like this, that don't run on native Linux... E.g. tests that verify our synthetic values inside /proc, tests that operate on UIDs/GIDs, etc.

Running this test manually would require adding 123 and 321 users. Wouldn't that be enough for manual tests, to ask the user to create such users (possible in a separate user namespace).

[g2flyer]

Reviewable status: 1 of 2 files reviewed, 1 unresolved discussion, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel) (waiting on @kailun-qin and @oshogbo)

---

libos/test/regression/rename_unlink.c line 230 at r2 (raw file):

Previously, dimakuv (Dmitrii Kuvaiskii) wrote…

@mkow We already have a bunch of tests like this, that don't run on native Linux... E.g. tests that verify our synthetic values inside /proc, tests that operate on UIDs/GIDs, etc.

Running this test manually would require adding 123 and 321 users. Wouldn't that be enough for manual tests, to ask the user to create such users (possible in a separate user namespace).

You don't need to create these users (in sense of adding them to passwd/groups/shadow and home directories et al). It still works even if they do not exist as long as you run them as root (which seems kindof conceptually required as these test-cases really make sense mostly for root/setuid commands). (I validated it for this program but i've seen that also in lots of past cases when you untar tar-files with unknown identities/groups ...)

PS: sorry for first replying directly in github: Still too much muscle memories from other projects where you just click in email and directly reply from github ...

[dimakuv]

Reviewable status: 1 of 2 files reviewed, 1 unresolved discussion, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel) (waiting on @kailun-qin and @oshogbo)

---

libos/test/regression/rename_unlink.c line 230 at r2 (raw file):

Previously, g2flyer (Michael Steiner) wrote…

You don't need to create these users (in sense of adding them to passwd/groups/shadow and home directories et al). It still works even if they do not exist as long as you run them as root (which seems kindof conceptually required as these test-cases really make sense mostly for root/setuid commands). (I validated it for this program but i've seen that also in lots of past cases when you untar tar-files with unknown identities/groups ...)

PS: sorry for first replying directly in github: Still too much muscle memories from other projects where you just click in email and directly reply from github ...

I agree with @g2flyer -- this test is conceptually a root-user test. So it will work even on vanilla Linux (but under root). This is similar to how certain LTP tests require running them as root.

[mkow]

Reviewable status: 1 of 2 files reviewed, 1 unresolved discussion, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel) (waiting on @kailun-qin and @oshogbo)

---

libos/test/regression/rename_unlink.c line 230 at r2 (raw file):

@mkow We already have a bunch of tests like this, that don't run on native Linux... E.g. tests that verify our synthetic values inside /proc, tests that operate on UIDs/GIDs, etc.

Yeah, but these are explicitly testing something Gramine-only or explicitly root-only. This is a generic rename and unlink test.

I agree with @g2flyer -- this test is conceptually a root-user test. So it will work even on vanilla Linux (but under root).

My idea/question was to change this test so it still tests this functionality, but in some other way which doesn't require root. So, it's not possible? Is woju's solution is too complicated?

[g2flyer]

Reviewable status: 1 of 2 files reviewed, 1 unresolved discussion, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel) (waiting on @kailun-qin and @oshogbo)

---

libos/test/regression/rename_unlink.c line 230 at r2 (raw file):

Previously, mkow (Michał Kowalczyk) wrote…

@mkow We already have a bunch of tests like this, that don't run on native Linux... E.g. tests that verify our synthetic values inside /proc, tests that operate on UIDs/GIDs, etc.

Yeah, but these are explicitly testing something Gramine-only or explicitly root-only. This is a generic rename and unlink test.

I agree with @g2flyer -- this test is conceptually a root-user test. So it will work even on vanilla Linux (but under root).

My idea/question was to change this test so it still tests this functionality, but in some other way which doesn't require root. So, it's not possible? Is woju's solution is too complicated?

What Wojtek outlines seems the best you can get as non-root. That said, is that really worth the additional complexity/obscuring of the actual test you want to check and the potential risk that due to other issues you actually might only run restricted tests in the actual CI? My take would have been that these tests you run natively exactly and only to initially validate that they correctly interpret POSIX behavior (at least Linux's interpretation thereof ;-) and afterwards wouldn't really touch them anymore? So should really happen only rarely and then running as root is really not a problem? But I guess not worth a hill to die on, this discussion probably already took way longer than it should have ...

[dimakuv]

Reviewable status: 1 of 2 files reviewed, 1 unresolved discussion, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel) (waiting on @kailun-qin and @oshogbo)

---

libos/test/regression/rename_unlink.c line 230 at r2 (raw file):

Previously, g2flyer (Michael Steiner) wrote…

What Wojtek outlines seems the best you can get as non-root. That said, is that really worth the additional complexity/obscuring of the actual test you want to check and the potential risk that due to other issues you actually might only run restricted tests in the actual CI? My take would have been that these tests you run natively exactly and only to initially validate that they correctly interpret POSIX behavior (at least Linux's interpretation thereof ;-) and afterwards wouldn't really touch them anymore? So should really happen only rarely and then running as root is really not a problem? But I guess not worth a hill to die on, this discussion probably already took way longer than it should have ...

I agree with @g2flyer -- it feels too complicated. I's prefer to keep it simple. I guess we could also just assume that native versions will run in a "root" Docker container (then no changes to the test are needed)? This seems like a fair and simple assumption.

[mkow]

Reviewable status: 1 of 2 files reviewed, 1 unresolved discussion, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel) (waiting on @kailun-qin and @oshogbo)

---

libos/test/regression/rename_unlink.c line 230 at r2 (raw file):

My take would have been that these tests you run natively exactly and only to initially validate that they correctly interpret POSIX behavior (at least Linux's interpretation thereof ;-) and afterwards wouldn't really touch them anymore?

That's what we do right now (or at least me when reviewing new tests), but the tests are being changed from time to time and it's always better if you can assert some properties automatically in CI.
So, it's a trade-off between the amount of stuff tested in-gramine and how much native compatibility we can assert in CI.

One idea to improve the trade-off in this PR: maybe you could refactor-out the root-only tests from this test to a separate one? The subtests from the old rename_unlink test didn't require root, so it would be nice to be able to still run them without root.

I guess we could also just assume that native versions will run in a "root" Docker container (then no changes to the test are needed)? This seems like a fair and simple assumption.

Dunno if that will work well, but it's some idea to try. @oshogbo is looking into this, he can probably say something more on that.

[dimakuv]

Reviewable status: 1 of 7 files reviewed, 1 unresolved discussion, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel), "fixup! " found in commit messages' one-liners (waiting on @kailun-qin and @oshogbo)

---

libos/test/regression/rename_unlink.c line 230 at r2 (raw file):

One idea to improve the trade-off in this PR: maybe you could refactor-out the root-only tests from this test to a separate one?

Good idea, done.

Please note that there is one sub-test test_rename_follow that was added in this PR, but this test actually doesn't have to do anything with fchown support (the point of this PR). So I don't know -- should I create a separate PR that adds this test_rename_follow sub-test separately? Or we can close our eyes on this and merge as-is?

[mkow]

Reviewed 6 of 6 files at r3, all commit messages.
Reviewable status: all files reviewed, 7 unresolved discussions, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel), "fixup! " found in commit messages' one-liners (waiting on @dimakuv)

---

libos/test/regression/rename_unlink.c line 230 at r2 (raw file):

Previously, dimakuv (Dmitrii Kuvaiskii) wrote…

One idea to improve the trade-off in this PR: maybe you could refactor-out the root-only tests from this test to a separate one?

Good idea, done.

Please note that there is one sub-test test_rename_follow that was added in this PR, but this test actually doesn't have to do anything with fchown support (the point of this PR). So I don't know -- should I create a separate PR that adds this test_rename_follow sub-test separately? Or we can close our eyes on this and merge as-is?

I'm fine with keeping it here, it's just a test.

---

libos/test/regression/rename_unlink.c line 203 at r3 (raw file):

        errx(1, "wrote less bytes than expected");

    should_contain("file opened before it's renamed", fd, message2, message2_len);

Please static_assert that message2 is longer than message1 (otherwise this check doesn't work, right? message1 won't be fully overwritten).

---

libos/test/regression/rename_unlink_fchown.c line 7 at r3 (raw file):

/*
 * Tests for fchown after renaming and deleting files. Mostly focus on cases where a file is still

Suggestion:

Mostly focused

---

libos/test/regression/rename_unlink_fchown.c line 28 at r3 (raw file):

#include "rw_file.h"

static const char message1[] = "first message\n";

Suggestion:

message

---

libos/test/regression/rename_unlink_fchown.c line 29 at r3 (raw file):

static const char message1[] = "first message\n";
static const size_t message1_len = sizeof(message1) - 1;

Suggestion:

message_len

---

libos/test/regression/rename_unlink_fchown.c line 89 at r3 (raw file):

    if (st.st_uid != 123 || st.st_gid != 123)
        err(1, "wrong ownership of file %s", path1);
    if (st.st_mode & S_IRWXO)

That's a weird check, why not checking whether the perms match exactly what the file was chmoded to?

---

libos/test/regression/rename_unlink_fchown.c line 107 at r3 (raw file):

    if (st.st_uid != 321 || st.st_gid != 321)
        err(1, "wrong ownership of (renamed) file %s", path2);
    if (!(st.st_mode & S_IRWXO))

ditto

---

libos/test/regression/rename_unlink_fchown.c line 129 at r3 (raw file):

    if (fchown(fd, /*owner=*/123, /*group=*/123) != 0) /* dummy owner/group just for testing */
        err(1, "fchown");

Could you verify with fstat that the perms were actually changed?

[dimakuv]

Reviewable status: 5 of 7 files reviewed, 7 unresolved discussions, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel), "fixup! " found in commit messages' one-liners (waiting on @mkow)

---

libos/test/regression/rename_unlink.c line 203 at r3 (raw file):

Previously, mkow (Michał Kowalczyk) wrote…

Please static_assert that message2 is longer than message1 (otherwise this check doesn't work, right? message1 won't be fully overwritten).

Done.

---

libos/test/regression/rename_unlink_fchown.c line 7 at r3 (raw file):

/*
 * Tests for fchown after renaming and deleting files. Mostly focus on cases where a file is still

Done.

---

libos/test/regression/rename_unlink_fchown.c line 28 at r3 (raw file):

#include "rw_file.h"

static const char message1[] = "first message\n";

Done.

---

libos/test/regression/rename_unlink_fchown.c line 29 at r3 (raw file):

static const char message1[] = "first message\n";
static const size_t message1_len = sizeof(message1) - 1;

Done.

---

libos/test/regression/rename_unlink_fchown.c line 89 at r3 (raw file):

Previously, mkow (Michał Kowalczyk) wrote…

That's a weird check, why not checking whether the perms match exactly what the file was chmoded to?

Done.

---

libos/test/regression/rename_unlink_fchown.c line 107 at r3 (raw file):

Previously, mkow (Michał Kowalczyk) wrote…

ditto

Done.

---

libos/test/regression/rename_unlink_fchown.c line 129 at r3 (raw file):

Previously, mkow (Michał Kowalczyk) wrote…

Could you verify with fstat that the perms were actually changed?

Done.

[mkow]

Reviewed 1 of 2 files at r4, all commit messages.
Reviewable status: 6 of 7 files reviewed, 3 unresolved discussions, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel), "fixup! " found in commit messages' one-liners (waiting on @dimakuv)

---

libos/test/regression/rename_unlink.c line 203 at r3 (raw file):

Previously, dimakuv (Dmitrii Kuvaiskii) wrote…

Done.

I mean, please assert here - with the assert being placed 170 lines above from here we won't know why we have this weird limitation after merging this PR.
Here we have the exact line which requires that.

---

libos/test/regression/rename_unlink_fchown.c line 89 at r3 (raw file):

Previously, dimakuv (Dmitrii Kuvaiskii) wrote…

Done.

Hmm, sorry for another round, but this is extremely unreadable now... Can we switch to octal notation?
I generally agree with https://lwn.net/Articles/696227/ and our styleguide on this, but we don't have PERM_* here, so I'd go with octal.

[dimakuv]

Reviewable status: 5 of 7 files reviewed, 3 unresolved discussions, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel), "fixup! " found in commit messages' one-liners (waiting on @mkow)

---

libos/test/regression/rename_unlink.c line 203 at r3 (raw file):

Previously, mkow (Michał Kowalczyk) wrote…

I mean, please assert here - with the assert being placed 170 lines above from here we won't know why we have this weird limitation after merging this PR.
Here we have the exact line which requires that.

Done.

---

libos/test/regression/rename_unlink_fchown.c line 89 at r3 (raw file):

Previously, mkow (Michał Kowalczyk) wrote…

Hmm, sorry for another round, but this is extremely unreadable now... Can we switch to octal notation?
I generally agree with https://lwn.net/Articles/696227/ and our styleguide on this, but we don't have PERM_* here, so I'd go with octal.

Done.

[mkow]

Reviewed 2 of 2 files at r5, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel), "fixup! " found in commit messages' one-liners (waiting on @dimakuv)

---

libos/test/regression/rename_unlink_fchown.c line 89 at r3 (raw file):

Previously, dimakuv (Dmitrii Kuvaiskii) wrote…

Done.

Why the casts though? Were they needed?

[dimakuv]

Reviewable status: 6 of 7 files reviewed, 1 unresolved discussion, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel), "fixup! " found in commit messages' one-liners (waiting on @mkow)

---

libos/test/regression/rename_unlink_fchown.c line 89 at r3 (raw file):

Previously, mkow (Michał Kowalczyk) wrote…

Why the casts though? Were they needed?

Done. Removed them. I thought it was cleaner, but can remove them as well, sure.

[mkow]

Reviewed 1 of 1 files at r6, all commit messages.
Reviewable status: all files reviewed, all discussions resolved, "fixup! " found in commit messages' one-liners

---

libos/test/regression/rename_unlink_fchown.c line 89 at r3 (raw file):

Previously, dimakuv (Dmitrii Kuvaiskii) wrote…

Done. Removed them. I thought it was cleaner, but can remove them as well, sure.

I think this is well known and idiomatic "Linux C", no need for the loud casts IMO.

[mkow]

Reviewed 4 of 4 files at r7, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved

[kailun-qin]

Reviewed 1 of 2 files at r1, 1 of 2 files at r5, 1 of 1 files at r6, 4 of 4 files at r7, all commit messages.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @dimakuv)

---

libos/test/regression/rename_unlink.c line 186 at r7 (raw file):

    int fd = create_file(path1, message1, message1_len);
    if (fd < 0)
        err(1, "create %s", path1);

it's handled in create_file(), do we still need this?

Code quote:

    if (fd < 0)
        err(1, "create %s", path1);

---

libos/test/regression/rename_unlink_fchown.c line 11 at r7 (raw file):

 * these tests require a root user to perform fchown with arbitrary user/group.
 */

As this is a newly-added test file, should we follow our convention (e.g., using CHECK() etc)?

---

libos/test/regression/rename_unlink_fchown.c line 77 at r7 (raw file):

    int fd = create_file(path1, message, message_len);
    if (fd < 0)
        err(1, "create %s", path1);

ditto

Code quote:

    if (fd < 0)
        err(1, "create %s", path1);

---

libos/test/regression/rename_unlink_fchown.c line 90 at r7 (raw file):

        err(1, "wrong ownership of file %s", path1);
    if ((st.st_mode & 0777) != 0660)
        err(1, "wrong permissions of file %s", path1);

Is it better that we refactor this into a check_ownership_and_permissions() helper?

Code quote:

    if (stat(path1, &st) != 0)
        err(1, "Failed to stat file %s", path1);
    if (st.st_uid != 123 || st.st_gid != 123)
        err(1, "wrong ownership of file %s", path1);
    if ((st.st_mode & 0777) != 0660)
        err(1, "wrong permissions of file %s", path1);

---

libos/test/regression/rename_unlink_fchown.c line 108 at r7 (raw file):

        err(1, "wrong ownership of (renamed) file %s", path2);
    if ((st.st_mode & 0777) != 0666)
        err(1, "wrong permissions of (renamed) file %s", path2);

ditto

Code quote:

    if (stat(path2, &st) != 0)
        err(1, "Failed to stat (renamed) file %s", path2);
    if (st.st_uid != 321 || st.st_gid != 321)
        err(1, "wrong ownership of (renamed) file %s", path2);
    if ((st.st_mode & 0777) != 0666)
        err(1, "wrong permissions of (renamed) file %s", path2);

---

libos/test/regression/rename_unlink_fchown.c line 152 at r7 (raw file):

    test_rename_fchown_fchmod(path1, path2);
    test_unlink_fchown(path1);
    printf("TEST OK\n");

-> puts

Code quote:

printf

[dimakuv]

Reviewable status: 5 of 7 files reviewed, 3 unresolved discussions, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel) (waiting on @kailun-qin and @mkow)

---

libos/test/regression/rename_unlink.c line 186 at r7 (raw file):

Previously, kailun-qin (Kailun Qin) wrote…

it's handled in create_file(), do we still need this?

Done.

---

libos/test/regression/rename_unlink_fchown.c line 11 at r7 (raw file):

Previously, kailun-qin (Kailun Qin) wrote…

As this is a newly-added test file, should we follow our convention (e.g., using CHECK() etc)?

Done

Note that I added CHECK() only in those places where we don't need an explicit clear error message. In other places, I kept the err() way, to have a better message.

---

libos/test/regression/rename_unlink_fchown.c line 77 at r7 (raw file):

Previously, kailun-qin (Kailun Qin) wrote…

ditto

Done.

---

libos/test/regression/rename_unlink_fchown.c line 90 at r7 (raw file):

Previously, kailun-qin (Kailun Qin) wrote…

Is it better that we refactor this into a check_ownership_and_permissions() helper?

Done. I didn't add stat() in there, since we can have stat or fstat syscalls, so it would be cumbersome to choose which calls needs to be done.

---

libos/test/regression/rename_unlink_fchown.c line 108 at r7 (raw file):

Previously, kailun-qin (Kailun Qin) wrote…

ditto

Done

---

libos/test/regression/rename_unlink_fchown.c line 152 at r7 (raw file):

Previously, kailun-qin (Kailun Qin) wrote…

-> puts

Done.

[kailun-qin]

Reviewed 2 of 2 files at r8, all commit messages.
Reviewable status: all files reviewed, all discussions resolved, not enough approvals from different teams (1 more required, approved so far: Intel)

[mkow]

Reviewed 2 of 2 files at r8, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved

[dimakuv]

Jenkins, retest Jenkins-SGX-22.04 please

[dimakuv]

Jenkins, retest Jenkins-SGX-24.04 please