bootstrap.sh makes your $HOME public #159

Closed
jonmz opened this Issue Dec 5, 2012 · 6 comments

Comments

Projects
None yet
5 participants

jonmz commented Dec 5, 2012

The README instructs you to do the following:

git clone https://github.com/mathiasbynens/dotfiles.git && cd dotfiles && source bootstrap.sh

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 https://github.com/mathiasbynens/dotfiles.git
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 bootstrap.sh 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.

Contributor

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, bootstrap.sh 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.

Owner

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 bootstrap.sh) 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).

http://linux.die.net/man/1/rsync

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.

Owner

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 bootstrap.sh: Don’t make the home directory world-readable
Fixes #159.
5be4832

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

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