I am to understand about the real logic of SUID as far I have learnt about it.
Taking example of /usr/bin/sudo file
If SUID sets the other user as temporary owner of that file (on which SUID is set) to execute it,
then
instead of using concept of SUID, why didn't the system directly give "others" the execute permissions which would have served the same purpose.
If the other becomes the temporary owner of the executable, then it should be able to run it with same functionality as its owner would, But we see that in sudo by non-root(non-owner) , password is asked and with root doing su, no password is asked.
sudoers gives you more access control.
A suid binary you can give execute access to owner-user, owner-group, world. With ACLs you can add additional users and groups (if the filesystem supports ACLs).
In sudoers you can allow multiple users and groups, which may be local/native (Unix style) or from a directory service (ActiveDirectory, M$-Windows style).
sudoers allows executable scripts.
The Linux kernel does not trust scripts; a suid bit on a script is ignored. In sudoers you can put scripts like binaries. (But most Unix flavors do support suid scripts; then some script interpreters require an option in the shebang).
You answer has lot of explanation and information, but not of point to my question's context.
I just took an example of sudo file , my main point of concern was regarding necessity of SUID bit
Simply, I need to know , what different functionality is being rendered by making the other as temp-owner of the command files (sudo, passwd, ping etc) when the same thing can be achieved by giving 'others' execute permissions (i.e Why at all the concept of SUID is developed and required).
My 2nd question has Implementation of what is said in 1st question, But not the reason to that.
If the other becomes the temp-owner of the command, then it should be able to run it with same functionality as its owner would, But we see that in sudo by temp-owner , password is asked and with root doing su, no password is asked.
by temp-owner(use of SUID):
$ sudo
password :
(If I have become the owner of sudo file,though temporarily, then why I am being asked password to enter, Owner doesn't need to give password logically)
Perhaps I don't understand your questions.
If you ask why only a privileged user may do certain actions, then the answer is "security". A vulnerable web browser may destroy the user's home directory but not the whole system.
If you ask why suid is invented, then the answer is "convenience". Without suid tools you must login as a privileged user in order to run a command like passwd. The suid su command lets you directly start a privileged shell. The suid sudo command lets certain users run certain commands, with the user's password or perhaps without a password. The suid ping can be directly run by a normal user, without the help of su or sudo.
The "sudo" rules are in "sudoers" (that may consist of /etc/sudoers and fragment files in /etc/sudoers.d/).
A NOPASSWD: prefix means it won't ask for a password.
To check what is allowed, run
Try not to confuse the subtle difference between 'sudo' and 'suid'.
Example 1 - SUID
There are many instances where an ordinary (not sudo authorised) user needs to amend a file e.g. /etc/passwd (or /etc/shadow depending on the distro) to which that ordinary user would normally have zero access to. Not even allowed to read it, let alone write/amend it. But when this ordinary user wants to change his password he needs to amend the file containing his (hashed) password which is a file that he has zero access to. So the passwd command that can be run by anyone on the system need to allow write access to /etc/passwd. It does this by SUID because the command runs with owner access giving write access to that file BUT only whilst that passwd command is executing. Immeditately that the command terminates so does the write access to that file. If the ordinary user was to try and edit that file immediately afterwards, access is refused. So to answer your post, it's not necessarily the execution rights that matter but more likely the access to other files that it needs to read/write.
Example 2 - sudo
'sudo' is a mechanism that the sysadmin can grant an ordinary user 'superuser' powers to run (any) command with enhanced powers. Such a user must be trusted and authorized in 'sudoers' file. This is subtly different to SUID but, once again, the command only has enhanced power until it terminates. Such a sudoer user can issue command after command using 'sudo' if they need to and are trusted not to be up to mischief.
'sudo' is much more powerful than 'suid'.
'sudo' is used by a very trusted user.
'suid' is used to allow an ordinary user to do stuff like change their password.
Will try to put in a more simpler way, what I was digging deep.
stay tuned.
@MadeInGermany - You are always here to help, Your explanations are helpful.
May be I put questions in certain way to be not clear to understand ,
Will try to be more clear.
any user cannot access /etc/password and /etc/shadow
/usr/bin/passwd command changes the password by writing to these files
But user cannot be given direct access (else any user can change any data in this)
So /usr/bin/passwd command was devised to give limited access to user on these files only to change its own password only.
/usr/bin/passwd command has execute permission for all users
Not with this known, my question was :
if any user can execute /usr/bin/passwd and this file has functionality to allow the executing user to change its password only, then what's the use of temporarily changing ownership for /usr/bin/passwd while executing(through use of SUID bit)
Would like to have views on this.
BTW, analyzing deeply, I think I have got the answer myself , will share after having your views on same.
/usr/bin/passwd is owned by root; the suid bit makes it run as root. And root (uid 0) has control over all the files on the system.
But the program code only makes changes to /etc/passwd and /etc/shadow, and even limits to the line that belongs to the calling user.
Without the suid bit a program won't get other rights than the calling user.
In Unix a process inherits the attributes (owner and rights) of the calling process. The suid bit is the only exception.
I was thinking something differently which would even be possible.
User gets root ownership because without that, it cannot write to /etc/passwd .
But what was on my mind is that , /usr/bin/passwd's code is such that it catches the username (who is executing it) in it along with the new password supplied , so that it knows what line (corresponding to that user) to update in /etc/passwd.
This doesn't require making the user temporarily the root. Only requirement for making the user temporarily root is to let that write to the /etc/passwd.
So the code itself may have been such to update that line (without giving the ownership), as the code already know what user and what password to update. Internally in /usr/bin/passwd it may have been coded to update that line.
in this way, user only executes /usr/bin/passwd and supplies password data w/o being root and all other functionality is done by code itself using already having root ownership
I am not intelligent as the makers of Unix, to be very respectful, but this though naturally comes to my mind. May be incorrect.
You are correct.
As an experiment you can make /etc/passwd and /etc/shadow world-writable and remove the suid from /usr/bin/passwd.
Then run passwd and change your pw. It should work.
Don't forget to restore all the permissions afterwards!
And before the experiment make a backup/snapshot of your system.
You say I am correct but you haven't got it right.
I didn't say to make /etc/passwd and /etc/shadow world-writable.
I said only to have /usr/bin/passwd functional code to be able to write to them as root,
But this may still not be possible because the action is happening in one shot (user executing the /usr/bin/passwd and needs to write to root-owned files).
So in my approach, there lies a 2nd command file which runs to update the /etc/passwd & /etc/shadow.
If there is an exec of a second command file, then the second command file must be suid root.
Perhaps you have this in mind:
Many Linux distros have policy kit, where an action is performed by a process which is running as root (service daemon). A not privileged command talks to it through a message API, "do this action for me".
The Solaris OS has RBAC. Where, I think, the kernel does the right escalation.
,
, /usr/bin/passwd's code is such that it catches the username (who is executing it) in it along with the new password supplied , so that it knows what line (corresponding to that user) to update in /etc/passwd.