Linux Permission: Sticky Bit Behaviors

Question

I am doing a practice task where I need to set appropriate file (and directory) permissions in Linux (Ubuntu), but I have encountered some weird behaviors that I do not understand.

---

I have done these as the root user:

For /shared I have set the directory permission to 1755, and ls -l showed drwxr-sr-t. This directory beings to root:root.

Added a file: /shared/rnd/rnd-test

For /shared/rnd and its contents I have set directory permission to 3770 (using chmod -r), and ls -l showed drwxrws--T. This directory as well as rnd-test beings to root:rnd.

trent is a user of the rnd group (confirmed with id trent).
walter is a user of the rnd group (confirmed with id walter).

As trent, created a file called trent-test.
As walter, created a file called walter-test.

---

Now ls -l /shared/rnd looks like this:
total 12
-rwxrwx--T 1 root rnd 60 Jan 29 20:17 rnd-test
-rw-rw-r-- 1 trent rnd 12 Jan 29 19:19 trent-test
-rw-rw-r-- 1 walter rnd 7 Jan 29 20:18 walter-test

---

As trent, cat rnd-test had no error.
As walter, cat rnd-test had no error.

---

Problems

As trent, echo 'trent' >> rnd-test had no error.
As trent, echo 'trent' >> walter-test had permission denied.

As walter, echo 'walter' >> rnd-test had no error.
As walter, echo 'walter' >> trent-test had permission denied.

As root, echo 'root' >> rnd-test had no error.
As root, echo 'root' >> trent-test had permission denied.
As root, echo 'root' >> walter-test had permission denied.

---

Intentions

1. Task required that files created by one user can only be deleted by that user. (Sticky Bit)
2. Task required that group files should automatically owned by the group. (SGID)
3. Anyone outside of the group should not have access to the group files. (0 for other users)
4. Group members should be able to access their group files. (7 for the group)

Based on these requirements I set 0755 for /shared and 3770 for /shared/*.

In fact, the requirements did not specify whether group members should be able to modify group files, but I am not clear why trent can modify rnd-test (owned by root:rnd) but not walter-test (owned by walter:rnd).

Sticky Bit Behaviors

If I were to set /shared/rnd permission to 1770 or 3770 (with the sticky bit), they were not able to modify (append).

If I were to set /shared/rnd permission to 0770 or 2770 (without the sticky bit), trent and walter was able to modify (append) walter-test and trent-test respectively.

I understand that some tools such as vim would delete the file first when trying to 'modify', but does echo >> also do that?

Answer 1

I did more research, and found this reply. Thanks to @grifferz.

@grifferz mentioned that recent changes in Linux had further prevented users from writing other users' files even if they are in the same group.

This protection is similar to protected_fifos, but it avoids writes to an attacker-controlled regular file, where a program expected to create one.

According to the fs.protected_regular documentations, while protected_regular is set to 2 (which my system had) it also applies to group writable sticky directories.

I changed it to 0 and the sticky bit behaved as it 'supposed' to be.

As for the 'writable' /shared/rnd/rnd-test (owned by root), it was because the /shared directory had 1755 set for permissions. I am not sure why but it magically allowed me to write rnd-test. It became un-writable (before protected_regular was changed) soon as I changed its permissions to 0755.