How the Operating system prevents normal users from executing commands like fdisk and umount eventhough the commands have execute permissions for everyone ?
[root@r7prd1 ~]# ls -la $(which umount)
-rwsr-xr-x. 1 root root 31960 Aug 21 2015 /usr/bin/umount
[root@r7prd1 ~]# ls -la $(which fdisk)
-rwxr-xr-x. 1 root root 182472 Aug 21 2015 /usr/sbin/fdisk
There probably may be some situations when it may be worth to disallow user to execute any binaries (I suppose it may be one of countermeasures against privilege escalation exploits). But in many cases regular users are able to execute their own binaries, so what if user will write and compile fdisk or something similar by himself? Really, you don't want to disallow user to run fdisk. You just want to disallow fdisk or any other program to modify the system state in some way. So regular user really can execute fdisk:
$ fdisk --help
Usage:
fdisk [options] <disk> change partition table
fdisk [options] -l [<disk>] list partition table(s)
...
What regular user actually cannot do is executing restricted operations:
$ fdisk /dev/sda
Welcome to fdisk (util-linux 2.27.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
fdisk: cannot open /dev/sda: Permission denied
So fdisk started successfully, printed some messages. Then it tried to open raw disk device /dev/sda and it was that operation that was really restricted by permissions, so fdisk just complained that it cannot do anything and exited.
There are some cases, though, when you may want to restrict executability of some binaries by some users. When administrator or OS maintainer want regular user to be able to execute some privileged action (such as mounting some partition that this particular user is allowed to by some record in the /etc/fstab), them set up some special hardened binaries such as mount or sudo with set-user-ID permission:
$ ls -l /bin/mount /usr/bin/sudo
-rwsr-xr-x 1 root root 40152 May 27 02:31 /bin/mount
-rwsr-xr-x 1 root root 136808 Aug 17 16:20 /usr/bin/sudo
When such binary is executed, the kernel gives it not the user ID of the calling user, but, in this case, UID 0 (root). Because regular user cannot set binaries up this way (root owner and set-UID bit set), then it may be theoretically worth restricting executability of these binaries to some particular group (but in the above case, they are world-executable and check permissions of calling user by themselves. I don't really know, if executability restrictions of set-UID executables cannot be circumvented in some way and whether such as approach is really widely used by someone).
And one extra note: in case of fdisk on your system, it is installed to /usr/sbin directory that may or may not be in the PATH variable of regular users, so fdisk may or may not be executed by regular user by just typing fdisk at command prompt, but it is not really a restriction (one may simply specify full path to executable on the command line).