Differences between current version and predecessor to the previous major change of DotFile.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 11 | Last edited on Sunday, February 7, 2010 4:33:40 am | by AristotlePagaltzis | |
| Older page: | version 10 | Last edited on Sunday, February 7, 2010 4:25:29 am | by AristotlePagaltzis | Revert |
@@ -6,10 +6,16 @@
* Lack of privacy. If the user wants to make some files readable to other users on the machine, those files have to be put in a directory which is readable by those other users. But in order to access that directory, its parent directory also has to be readable by those users. And its parent, as appropriate, and so on right up the user’s home directory—the one containing all these dotfiles. So other users can at least see the names of those dotfiles, if not their contents, and thereby deduce what applications it’s likely you’re using. And it’s surprising how many of these items are created world-readable, so other users ''can'' see their contents.
''Other users need execute permission to traverse a directory, but they don't need read permission for it. Of course DotFile~s by and large have guessable names, so if you can traverse a user's home directory you can read their DotFile~s by blindly trying names like <tt>.bashrc</tt>. But note also that almost all of these files can be [chmod|chmod(1)]ded to non-world-readable with no drawbacks. In other words, this is near as big a concern as the above paragraph makes it out to be. —AristotlePagaltzis''
+
+ ''Assuming you remember to do that. Which still doesn’t change the fact that knowing those files exist already gives information away. –LawrenceDoliveiro''
+
+ ''You mean: Other users need read permission to list the names of items in a directory and execute permission to actually access those items. –LawrenceDoliveiro''
+
+ ''No. I meant exactly what I wrote, and it is correct. To access <tt>/home/ap/www/index.html</tt>, you need to traverse the root directory, <tt>home</tt>, <tt>ap</tt> and <tt>www</tt>, in order to get to <tt>index.html</tt>, so you need execute permission on each of those directories, but need read permission only on the file. —AristotlePagaltzis''
* Untidiness. Anything the user wants to create, has to be found by starting from the top level of their home directory. So at this top level, you have a whole bunch of items mixed together, some created explicitly by the user, others implicitly by apps run by the user. Yes, directory-listing utilities commonly offer the option to hide dotfiles and just show the others, but the opposite option seems a little harder to achieve.
For these reasons, it seems a good idea to give the user more control over where these preference files are created. The only serious proposal I know of is the [XDG Base Directory Specification|http://standards.freedesktop.org/basedir-spec/latest/]. This says that user prefs should be created in the directory specified by the EnvironmentVariable <tt>XDG_CONFIG_HOME</tt>. If this is not defined, then the prefs should go in the directory <tt>$HOME/.config/</tt>. The directory should be created if it doesn’t exist, to be readable and writable by the owner but inaccessible to anyone else.
Thus, all the dotfile clutter is replaced by a single dotted-directory name, and the user has the option of overriding even this.
