Classic Shell Scripting - Arnold Robbins [248]
When nondefault permissions are likely to be required, shell scripts should issue an explicit umask command near the beginning, and before any files are created. However, such a setting does not affect files that are redirected on the command line, since they are already open when the script starts.
The second most important tool is the chmod command: learn it well. Even in a permissive environment where read access is granted to everyone, there are still files and directories that must be more restricted. These include mail files, web browser history and cache, private correspondence, financial and personnel data, marketing plans, and so on. Mail clients and browsers generally set restrictive permissions by default, but for files that you create with a text editor, you may need to issue a chmod command yourself. If you are really paranoid, don't create the file with the text editor: instead, create an empty file with touch, run chmod, and then edit the file. That eliminates a window when there might be data in the file during initial editing that is more visible to others than you want.
You must also remember that system managers have full access to your filesystem, and can read any file. While most system managers consider it unethical to look inside user files without explicit permission from the file owners, some organizations consider all computer files, including electronic mail, their property, and subject to monitoring at any time. The legal issues on this remain fuzzy, and certainly vary around the world. Also, your site may have backups that go back a long time, and files can be recovered from them, possibly at the order of a court of law.
* * *
Encryption and Data Security
If you are really intent on storing files that (almost) no one but you can read, you need to use encryption. Because of various government export rules that classify cryptography as a weapon, most Unix vendors normally do not ship encryption software in standard distributions. Before you go off and install encryption software that you may have found on the Web, or bought commercially, we issue these caveats:
Security is a process, not a product. There is a fine book that you can read to learn more about this: Secrets and Lies: Digital Security in a Networked World (Wiley).
Should you ever forget your encryption key, or have an employee who leaves without passing on encryption keys, you have probably lost your data as well: good encryption methods generally cannot be broken in the time that you have available.
Just as you might change door locks when an employee leaves, you must also accept that the ex-employee's encryption keys are compromised, and with new keys, re-encrypt all files previously secured with the no-longer-trusted keys.
If the enhanced security of encrypted files makes life harder for users, they may simply stop using encryption. The same thing happens with complicated door locks: the doors just get propped open.
If you'd like to learn more about the fascinating history of (mostly failed) encryption algorithms, a good place to start is The Code Book: The Evolution of Secrecy from Mary, Queen of Scots, to Quantum Cryptography (Doubleday). If you are interested, you can then move on to the algorithmic details in Applied Cryptography: Protocols, Algorithms, and Source Code in C (Wiley). There are also extensive bibliographies that cover much of the literature of the field at http://www.math.utah.edu/pub/tex/bib/index-table.html.
* * *
Finally, in an era of networked computers, it is likely that you will at some time be separated from your filesystem, or your