Assuming the normal user wants to update his password at /etc/passwd.
Why it is preferable to set Setuid in a way such as -rws------ . I am assuming it works the same as if the other users will be given these privileges in a way such as -rwx---rwx.
Correct me if I am wrong because I may not actually understand this concept and therefore I would like someone to explain that to me.
The setuid bit (the s in -rws------) means that whenever the program runs, the created process wields the powers of the user who owns the program file. If admin owns the file, and john runs it, the resulting process runs under admin's effective user id. (While still carrying john as it's "real" user id.) The idea usually being that admin can do something that john or a regular user cannot, but the program can still do further checks to control what the running user tries to do.
With the permissions above, the setuid bit makes no sense, since no one other than the owner can run the program.
With -rwx---rwx permissions, anyone not a member of the file's group can execute the file, but they do it under their own user id. They don't get any additional rights through the program.
The key here is that /etc/passwd is a protected file. It should not be editable to anyone but the admins. On my Debian it is -rw-r--r--. It is not clear in your question what the SUID relates to. In no way would it make sense for /etc/passwd. It would only make sense for a program that might change /etc/passwd. But now, -rws------ doesn't make much sense for that program file, as ikkachu explained above. -rws---r-x would make sense, since then a regular user might run it. Still, remember the /etc/passwd is a protected file, and this protection should be taken into consideration while writing the executable that will do the change. The sticky bit doesn't apply to scripting languages for security reasons, btw.
In order to change his/her own password, the user needs to somehow get the new password hash written to /etc/shadow (or /etc/passwd on legacy systems with no shadow password implementation).
If the user is allowed write access to the file, then the user can change anything within that file: the user could change anyone's passwords, impersonate any user, and trivially gain root access. This is clearly not acceptable.
The solution is a "gatekeeper" that has the power to let the user perform one specific act with root-level access, namely change his/her own password only.
The /bin/passwd program is such a gatekeeper program. It is written very carefully to ensure that it will allow the changing of the user's own password only, unless the user is root (or, in some cases, has appropriate extra privileges). When the gatekeeper program is ready, its permissions are set so that the users can execute it, but not modify the program's contents. Then the setuid root permission is added to the program: it causes any process running that specific program to have root access for the duration of that specific process only.
Sometimes the permissions of setuid root programs are set to 4111, or ---s--x--x, so that non-root users are only allowed to execute the program, but not to read its contents in any other way.
There are some protections for setuid programs that are built-in to the operating system: for example, you cannot attach a debugger to a process that is running a setuid root program unless you are root. And if a setuid program happens to be readable by regular users, and a user attempts to make a copy of that program, the copy will usually lose the setuid permission bit; and even if it didn't, the copy will (normally) be owned by the user that made the copy, so it will no longer be setuid root but setuid [username], and most likely cannot do its job anyway.
