I noticed that SUID and SGID have also the upper-case S which means the file or directory has no execute permission.
If I change the permission of the binary file /usr/bin/passwd to -rwSr-xr-x, why a user can still use passwd to change his password? In this case the user will be promoted to root to execute the binary file as its owner. But root does not have execute permission.
The permission is getting checked first, before the effective user ID is changed to the file owner's user ID.
This probably was designed that way because it is more useful: if the SUID bit took effect before permissions were checked, then SUID programs would effectively just have one execute permission bits - either everyone could execute them or no one could.
Actually, to be more precise, the group execute permission would still work independently, so:
??s??????could be executed by everyone if SUID bit took effect before checking permissions.??S??-???could never be executed by anyone if SUID bit took effect before checking permissions.??S??x???could be executed by only people in the owning group if SUID bit took effect before checking permissions.By checking the permissions first, we can have other useful possibilities, since the "group" and "other" bits can still fully independently control the behavior.
It also means you can actually answer "can people in this group execute this?" and "can others execute this?" for any given file by just looking at the "group" and "other" execute bits (
?????x???vs?????-???and????????xvs????????-) without also having to always think "wait, is the SUID bit set?" - if the SUID bit took effect first, you'd have to always check for it just to know for sure if the "group" or "other" bits even do anything.