Query on the code in Race_Condition

[LuminousXLB]

I ran the vulp.c code snippet as below.

Before I setuid on vulp, it can normally modify the tmpfile. However, after I setuid, it fails with a segmentation fault.
I looked into the program and find that it passed the check of access but fails to open the file because of 'Permission denied'.
Is this an expected behaviour? Do you think we should check if fopen succeed and add a perro?

[kevin-w-du]

This has been working fine on my computer. Are you using the SEED VM? The background of your terminal does not seem to be the SEED VM.

[kevin-w-du]

All the labs need to be done on the SEED VM, or you will observe some issues. I just realized that the problem you identified in the SetUID lab might be caused by the same reason. I will double check, and we may have to roll back the change that I just merged.

[LuminousXLB]

All the labs need to be done on the SEED VM, or you will observe some issues. I just realized that the problem you identified in the SetUID lab might be caused by the same reason. I will double check, and we may have to roll back the change that I just merged.

I checked it again in the SEED VM. There're the same warnings.

[kevin-w-du]

OK, I see that you used "gcc -Wall" while I simply use "gcc". That makes sense. I will keep the changes.

[LuminousXLB]

This has been working fine on my computer. Are you using the SEED VM? The background of your terminal does not seem to be the SEED VM.

It also has the segmentation fault

[kevin-w-du]

Can you post a screenshot of your desktop?

[LuminousXLB]

[kevin-w-du]

I have recreated your problem. Let me figure out why. I tested this lab many times.

[kevin-w-du]

I see the problem. In the past, I never create /tmp/XYZ, because fopen will create one automatically. If we create one ourselves, the root will not have a permission to write to it, that's why it passes access but failed at open when vulp is a setuid program. We may have seen this problem before, but we always run vulp in a loop, so if it crashes, it didn't matter. I do remember seeing the message, but didn't spend time to figure it out. I have fixed the problem, just like what you have proposed.

[LuminousXLB]

That looks make sense.
Thank you.

[kevin-w-du]

I am reopening this issue for discussion. I am doing some comparison between Ubuntu 16.04 and 20.04, and found out that open() system call's behavior is different. In 16.04, root can open any file in /tmp; but in 20.04, root cannot do that. That is why we see the problem. Adding an error checking does not solve this problem, because the program becomes meaningless: it will never be able to write to /tmp/XYZ in the normal case.

I did a search, and found a way to disable this behavior. We need to run this command (see reference here)

sudo sysctl fs.protected_regular=0