Sometimes things are arbitrary. For instance, arbitrary conventions are often the result of arbitrary decisions. However, arbitrary decisions are rarely good decisions. And so it is with so-called "dot" files under Unix: they are an arbitrary convention that grew out of an arbitrary decision and have proven to be cumbersome. It is time for this convention to change.
Under the Unix system, programs that use special configuration or initialization files conventionally put these into a user's home directory with names that start with a dot (".") character. This takes advantage of a particular quirk of the Unix directory listing program, ls(1), which by default does not list files with names beginning with a period, thus keeping them out of sight of the user.
Unix dot files have two primary advantages. The first is that they follow a well-known convention, so using them carries little surprise for users who expect to be able to customize the programs they use by editing configuration files in their home directories. Developers can follow the established convention without going through a lengthy adoption process or using incompatible conventions (which would place a burden on the user). The second is that a program can usually be fairly certain that a user's home directory exists and has the appropriate permissions to house those files in the first place.
A secondary advantage is that the Unix ls program, by default, will not list those files. Thus, the user's view of his or her home directory is not generally cluttered by files that are sometimes useful but more frequently distracting.
A tertiary advantage is that some dot files are mandated by
certain operating systems standards. For instance, the POSIX family
of standards defines a standard shell resembling the Korn shell,
which looks for an initialization file named
"$HOME/.profile". Use of dot files thus helps some
systems conform to relevant standards.
Unfortunately, the use of the dot file convention carries with it significant disadvantages.
First, the entire convention hinges on what is arguably a quirk of the Unix ls program. Who decided that ls should not list files starting with a dot, and what was the rationale and purpose of this? Have the underlying assumptions ever been critically examined? More importantly, what if the behavior was a mistake? Some signs indicate that it may have been. Significantly, when the authors of Unix built their successor system, Plan 9, they removed this behavior.
But this is subjective and a matter of taste. Looking beyond such matters, the default behavior of ls can mask legitimate problems. For instance, a common trick used by those who wish to hide files from either system administrators or legitimate users is to put them into "dot directories," or directories with names beginning with a dot. The default behavior of ls makes it likely that such directories will be overlooked, and the large number of dot files in a typical user's home directory make it likely that, even if the user does look at a full listing of his or her directory, they will overlook the directory in question. In hacker circles, it is not uncommon to create directories with names beginning with a dot and containing space or other characters to act as file drop boxes.
As a young system administrator working in a University environment, I learned to alias the ls command to include options that showed me all files in the directory I was looking at in order to locate such things. Unfortunately, the value of doing that is diminished by the multitude of dot files now in a typical home directory.
Also, under some filesystems, such as AFS, individual file
permissions have no meaning and only permissions on the parent
directory are honored by the file server. By placing potentially
sensitive files directory into the user's home directory, their
contents are exposed to every user of the system, not just the
owner. Consider the case of a .k5users or
.rhosts file: exposing these gives away information
about what Kebreros principles are
allowed to access a user's account, or what other machines a user
may have an account on. This can give valuable information to an
attacker, including exposing aspects of network topology or
authentication interactions that could be leveraged to compromise
the security of an entire site, not just a single user's account.
Restricting access to a user's home directory could avoid this, but
may be unacceptable for other reasons.
Note: some may argue that that particular problem is best solved by not using Kerberos or BSD-style host authentication. The latter is certainly valid (the former is debatable), but that doesn't change the point. Instead of playing whack-a-mole with particular security problems, we'd like a more general mechanism to close the vector in general.
The case for hiding dot files is simple: they are usually distracting. Most times, the user neither cares nor wants to be reminded of their existence.
The simplest alternative is to designate a new conventional directory for configuration, initialization and history files.
I propose that programs adopt the convention of placing their
configuration files underneath the directory $HOME/etc/.
If the program only uses one configuration file, place that
directly into $HOME/etc. For instance, Mail(1)
might use $HOME/etc/mailrc.
If a program makes use of more than one file, then it creates a
directory for its use under $HOME/etc. For instance,
$HOME/etc/dbus, or $HOME/etc/emacs.
This mimmicks the conventional structure of the Unix system's root directory on a per-user basis, so should yield few surprises for individual users, allows the user to set permissions on the directory as she sees fit without restricting access to her home directory.
Too often, the open source community latches onto established Unix convention without giving due consideration, accepting without question things that where, in retrospect, mistakes.
The dot file convention was an arbitrary decision, and one that has caused numerous problems. It was, in retrospect, a mistake. It's time to correct it.
To the community: Please, standardize on a new convention and push adoption. To program maintainers: please, adopt the convention the community standardizes on. To users: Please, lobby vendors and projects to adopt that convention.