Please do not ask why, but is it possible to do it?
p/s: I know it's not a good thing, let's just say someone from the top management who is computer illiterate want some sort of control over the server.
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.Sign up to join this community
sudo is the swiss-army knife of customized permissions. You could ask the user
sudo /usr/bin/passwd root
To see how this might be enabled, here's a related example from the sudoers(5) manpage.
pete HPPA = /usr/bin/passwd [A-Za-z]*, !/usr/bin/passwd root The user pete is allowed to change anyone's password except for root on the HPPA machines. Note that this assumes passwd(1) does not take multiple usernames on the command line.
You'll have to invert the logic to achieve your ends, of course. So, you would execute the
visudo, and add a line like
user ALL = /usr/bin/passwd root
Maybe you can add this line to the sudoer file (using
phunehehe with the username.
phunehehe localhost = NOPASSWD: /usr/bin/passwd
I don't know if that breaks your condition of a "normal user", though, because after that he/she has so much power.
EDIT: as per xenoterracide's comment :)
Can't he use run level 1 to change root password?
What I have in mind is
The obvious disadvantage of this procedure is that machine has to be rebooted and while its in run level 1, it will be offline.
Kindly mention the flaws that you find in this procedure.
If your system used pam_tcb (tcb - the alternative to /etc/shadow) (and hence there were users' password files per user), you could also achieve what you want by managing file permissions and groups (say, add this user to the group that you make own the password file for root).
In this case, I don't see any principal differences in the results as compared to the
sudo-solution (if you are ready to trust
sudo, of course), because you are anyway giving away the highest privilege to that user.
But in other cases,
pam_tcb gives more flexibility and security: first, you ought not to trust
passwd in that they won't let the user exploit the privileges in an unwanted way; second, less privileges must be given to users to achieve certain similar configurations (and no setUID-root programs are needed at all) -- see, e.g., the question for a similar thing: Reset [another] user's password without root