makes your $HOME public #159

jonmz opened this Issue Dec 5, 2012 · 6 comments


None yet
5 participants

jonmz commented Dec 5, 2012

The README instructs you to do the following:

git clone && cd dotfiles && source

Cloning the repo without setting a umask actually creates a dotfiles directory whose permissions reflect the current umask, in most cases leading to a world-readable directory:

[jonas@catbert tmp]$ git clone
Cloning into 'dotfiles'...

[jonas@catbert tmp]$ ls -ld dotfiles
drwxrwxr-x 6 jonas jonas 4096 Dec  5 12:36 dotfiles

No problem until here. But then does the following:

rsync [...] -av . ~

... which does not sync the directory's content but the directory itself, including its permissions. After that, if dotfiles has been publically readable, $HOME is too, which really is unacceptable on a multi-user system.

Any Linux distro that I personally know (quite a couple) uses 002 or 022 as the default umask while useradd creates the home directory of a user with 007 or 077 as configured in /etc/login.defs, so on most systems the default installation process will lead to a privacy incident.

Please advise users that want to install your dotfiles to set an adequate umask before. Getting the permissions of their home directory incidently changed (without notice!) is quite surprising, and in many cases, dangerous.


richo commented Dec 5, 2012

If you don't want your home directory world readable, doesn't it stand to reason that you'll be setting your umask? Several utilities (admittedly, ones bugger all people use) such as plan(1) and finger(1) rely on a world readable home to begin with.

I'm not saying it's not an issue, but I think you are drawing this out of proportion somewhat.

jonmz commented Dec 5, 2012

The umask defines the default permissions of newly created files and directories, so I - from a user's perspective that already knows about the umask - never would expect that it could affect the permissions of any file or directory that already exists (and whose permissions I may have explicitly changed from the defaults).

plan and finger expect the home directory to be o+x, that's correct, but even if that's already the case, still adds o+r - and if it isn't, plan and finger expect the user to change its permissions which is then an action within his very own responsibility.

In contrast, installing the dotfiles as described in the README changes the permissions of the user's home directory without asking him and even without telling him - and, best of all, without any reason: Having a public home isn't even necessary for the use of dotfiles.

FWIW this caught me by surprise. In fact I hadn't noticed my homdir perms had changed, until reading this issue thread alerted me.


mathiasbynens commented Dec 27, 2012

Thanks for reporting this, @jonmz.

Adding a note to the README is fine to me.

However, I’d prefer to tweak the rsync command (or anything else in so that the issue is avoided. Is there an easy way to do so?

oxyc commented May 1, 2013

What about using rsync [...] -av --no-perms . ~? This would preserve all file permissions while still modifying executability.

-p, --perms This option causes the receiving rsync to set the destination permissions to be the same as the source permissions (See also the --chmod option for a way to modify what rsync considers to be the source permissions.)
When this option is off, permissions are set as follows:

  • Existing files (including updated files) retain their existing permissions, though the --executability option might change just the execute permission for the file.
  • New files get their lqnormalrq permission bits set to the source file's permissions masked with the receiving directory's default permissions (either the receiving process's umask, or the permissions specified via the destination directory's default ACL), and their special permission bits disabled except in the case where a new directory inherits a setgid bit from its parent directory.

Thus, when --perms and --executability are both disabled, rsync's behavior is the same as that of other file-copy utilities, such as cp(1) and tar(1).

Another option would be to temporarily enable dotglob and then rsync ./*, meaning the contents of the directory but not the directory itself. However I think the --no-perms flag is just what is needed.


mathiasbynens commented May 1, 2013

Thanks, @oxyc! Seems like the perfect solution :)

@mrkd mrkd added a commit to mrkd/dotfiles that referenced this issue Apr 21, 2014

@mathiasbynens @mrkd mathiasbynens + mrkd Don’t make the home directory world-readable
Fixes #159.

@thorsten thorsten pushed a commit to thorsten/dotfiles that referenced this issue Dec 12, 2014

@mathiasbynens mathiasbynens + Thorsten Rinne Don’t make the home directory world-readable
Fixes #159.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment