An error in file ownership episode on the lpic1 series and a couple of questions

---

On that episode you called the setuid and setgid the sticky bit.
Even though sticky bit is a different thing that you didn't explain.
The set uid (u+s) on a directory doesn't do anything.
But on a file that means that you can execute a program/script with the permissions of the owner of the file and not the user you're currently logged in as.
The set gid (g+s) on a file does the same thing as the setuid, but for the group permission instead of the user.
On a folder that means that the group of the directory would be the effective group and not the group of the user.
The sticky bit makes sure that no matter what the permissions of the directory, only the root user or the owner of the files inside the directory can remove it.
Otherwise if a directory has write permissions to "other" and the directory is shared. every user on the system can delete my files.
Setting the sticky bit on a specific file as far as I know doesn't do anything.
Often times the setgid and sticky bit goes hand in hand for folder sharing.
I think you should clarify it on the episode, and correct me if I'm mistaken at any point.

Now for the questions:

1. If I'm adding an acl entry to a file/directory for a group or user, and giving them a permission that doesn't exist on the group, it adds it automatically for the group itself.
   For example:
   I'm giving a file called test permissions of nothing 000 for the example.
   ----------. 1 ansible-user ansible-user 0 Dec 2 19:38 test
   Then I'm doing setfacl -m u:cloud_user:wrx test
   When I'm checking the posix regular permissions I see:
   ----rwx---+ 1 ansible-user ansible-user 0 Dec 2 19:38 test
   It happens no matter the original permissions.
   another example:
   -rw-rw-r--. 1 ansible-user ansible-user 0 Dec 2 19:44 test
   The same command would give me:
   -rw-rwxr--+ 1 ansible-user ansible-user 0 Dec 2 19:44 test
   Is that a normal behavior?
   Why the permissions of the main group changes even though I changed permissions for a different user or group?

2. If I'm creating a file at the root of the system (as root of course because only root can), and change the ownership to another user, I can't delete it as the user, only as root.
   when I'm seeing the permissions of the / directory, I see dr-xr-xr-x. 17 root root 224 Dec 2 19:36 /
   Is that some hidden mechanism of linux to prevent deletion of folders under the root directory even though I can't see it on the permissions because it doesn't have write permissions anywhere ?

The answer to question 1 is that it is normal behavior. In the background setfacl uses a permissions mask. No ACL entry can have permissions that exceed the default POSIX group's permissions. So when you create an ACL entry it will increase the default POSIX permissions to match the highest permission you have granted in the ACL. For example:

dpezet@Dons-Server:~$ touch test2.txt
dpezet@Dons-Server:~$ chmod 000 test2.txt
dpezet@Dons-Server:~$ ls -l test2.txt
---------- 1 dpezet dpezet 0 Dec  7 22:11 test2.txt
dpezet@Dons-Server:~$ setfacl -m u:root:r test2.txt
dpezet@Dons-Server:~$ ls -l test2.txt
----r-----+ 1 dpezet dpezet 0 Dec  7 22:11 test2.txt

I granted the root user read-only permissions, so it bumped the default group permissions up to read-only as well. The default user and group permissions serve as the "mask" for the ACL permissions.

For your second question, I am not sure off hand. The root folder does have special permissions. Some are provided by the Kernel itself, and some from the umask set by the distro. It could also be blocked by AppArmor or SE Linux.