I am writing a cronjob which changes default root password to some designated password(set) after 15 days. The requirement for same is because i need to give application team root access for first 15 days, but after that the default password should be changed, now I want to automate the entire process so I wrote this:
But my concern is that user while having root access can read the real root password from cron, so is there is a possibility where I can avoid the hard-coding of root password, while still achieving the objective.
There are quite a few objections to this entire approach. It is possible the the ap team will need to install a job in root's crontab. This would guarantee that they see your code. It also it means your "crontab -r" could be dangerous. If you must go down this path you can partially address your own objection. Switch to "usermod -p" and hard code the encrypted password. This is still terrible for security but it does beat hard coding the plaintext password.
But here is another approach for your consideration. Define a group called, perhaps, "bigshots". Add a line to /etc/group putting the ap team in the bigshots group. Now add a line like this:
%bigshots ALL=(ALL) NOPASSWD: ALL
to /etc/sudoers. Show the ap team how to use sudo to gain root power. And finally write a script to remove the bigshots line from both /etc/sudoers and /etc/group. This should be easy because we are using a screwy word like "bigshots" which probably will not collide with any other line in either file.
And the final touch: use the "at" command rather than "cron" to schedule the script at the appropiate time.
If you hand over access to root then you have no idea what they could insert. Consider that they put on a service for a port that they choose and have it run the Korn shell. From any other server, a simple telnet to that port will fire up a Korn shell and give them root access again.
There are a myriad of other possibilities too. You need to turn this completely around.
Find out:-
What they need to do
Why they think they must have root access
I would bet that they can't, but it's just convenient. I f you feel you really have to, use sudo to grant them the minimum privilege to do their work and if you have concerns that they could escape to a shell or set a script to SUID etc., then keep them away from it.
Even something as critical as creating an Oracle database does not need the DBA to have root authority. True, someone has to install the software and allocate disk space etc. but that is your job.
Perhaps have them tell you what to do and you drive the process if you are happy with it.
If you have a really great car and you give them the key, what's to stop them copying the key and borrowing it when you're not looking and getting you speeding points or just wrecking it and running away?
Would you give them the password and trust them to make an update on your on-line bank account without stealing the cash?
Be honest with yourself. If they mess it up, who is in the firing line?
Quite often we do not have a saying on the practices and polices of the systems we administrate. Most of the time, the circumstances are far from ideal.
Allow me to subject that you encrypt the password before hand. Even if they get the hash it cannot be reversed to find out what the password is.
chpasswd already allows you to accept the hash instead of the clear text
Use some utility to encrypt the password into a hash that match what you see in the /etc/shadow file.
Change "Some_password_I_want" for the real password
Change "random_string" for truly some make-up string of characters, I think if I remember correctly there's a limit as how long.
That will produce an output like:
blue is the type of hash
red is the salt
green is the encrypted password