Why should you NEVER edit the /etc/shadow file directly?

Question

In another answer here on UNIX & Linux Stack Exchange Michael D Parker wrote, in response to someone saying that doing so was "safe", that:

Usually you should NEVER edit the /etc/shadow file directly.

So:

Why should you never edit the /etc/shadow file directly?

Answer 1

There are several reasons not to edit /etc/passwd, /etc/shadow, /etc/group, /etc/gshadow or /etc/sudoers directly, but rather use vipw, vigr or visudo:

• If you make a syntax error, you may not be able to log in or become root anymore. Using the viXXX tools reduces this risk because the tool makes sanity checks before modifying the file.
• If the file is edited concurrently, whoever saves last will override the changes made by previous edits. This includes both an administrator editing the file and the file being modified because a user called passwd, chsh or chfn to change something about their account. If you use the appropriate tool, it will prevent concurrent modifications. This is mostly a concern on systems with multiple users, less so if you're the only user.
• On some systems (mostly or only *BSD), vipw updates multiple files (e.g. /etc/passwd and /etc/master.passwd). This doesn't apply to Linux.
• vipw automatically creates a backup (passwd-, shadow-, …), which is useful if you realize that you accidentally deleted a line. It's only useful if you realize before the next edit, so it doesn't replace version control and backups, but it can be very nice if you realize your mistake soon enough. visudo doesn't do this.

You can edit the file directly. You'll just be taking an additional risk with no real advantage.

Answer 2

There are basically two ways to look at this:

1. Never edit certain files without using the prescribed tools because you probably don't know what you're doing and that's ok because said tools know better and are always available.

2. More realistically, you might as well break it now while you're thinking about it so you can plan ahead with a backup copy and compare the differences after you do because basic knowledge about the ins and outs of your system's basic initial login process is probably worth having for when you break it some other way later and said tools will not help you.

I guess you can probably tell which I recommend. I say that if a topic interests you even for a moment you might as well capitalize on that curiosity and gain a new skill while you're at it. Especially one such as this - the shadow file is in a fairly basic format, and what little I know of it I learned after breaking it accidentally - and it wasn't the result of an edit I made to that file.

Rather my problem occurred after some other mistake with a package management database led the package manager to overwrite it without saving a backup and all users on the system were made kaput. Further ignorant bungling attempts at repairs only spread the damage to other related files and it wasn't long before I had to restore the majority of /etc's text files from a (less recent than hoped-for) backup.

Once I had done so and verified I had it in workable state, I decided to deliberately, meticulously do it all again. And once more. This was all a few months ago, but today I remain confident that I can diagnose the source of a login issue w/ a once-over of a single logfile on my system and address it with any basic editor (and provided, perhaps, a glance or two at man 5 problem_file) provided only basic access to the root fs affected. It was not cheaply gained - it took me most of a day - and the related config files are spread all over the directory (and even some - such as Linux PAM's /var/run/no_login - on other mounts) - but it was worth doing. And it could have been cheaper with a little forethought.

The moral of this story is that it is probably not a good thing that the format of mission-critical configs like shadow, passwd, groups, shells should be so opaque to us that we must employ special edit tools that may or may not correct our work in ways and for reasons we do not understand just to effect a simple change. At least, I think, it is worth our while to understand exactly what they would do differently than we might.

It probably is a good thing, however, that once we become familiar enough with editing said files that we run the risk of making within them and afterward saving to them typographical or simple syntactic errors that there are tools at our disposal which can double-check our work in ways and for reasons we already understand before applying our blase edits.

Answer 3

Counter point - if you needed to copy a set of user logins from one server to another, without knowing their current passwords or assigning them new ones, then you'd need to edit /etc/shadow directly to insert the hashed password field. vipw does not let you touch that field, it's just "*"

Update: or in this case use chpasswd -e "hashed password", but that can only be done on the computer directly. If you were working with a set of files that have yet to be deployed to a machine (e.g. Virtual Machine), then editing directly might be your only solution.

i.e. There is usually a tool for doing what you want to do without editing /etc/shadow directly, you just need to know what it is...

Answer 4

Another reason you need to edit these files is if you are editing the files in a filesystem image that you will be booting on another system, and you need to debug that system after boot. For example, the MAAS epheremal filesystem used on a failing comissioning or in rescue mode.

Never say never... unless you mean it.