5 ms·

The issue isn't specific to home directories. /tmp, for example. Your suggestion may protect against accidents, but doesn't seem to me to do anything for delib

• kazinator 5y ago
  Right, so someone could create a malicious /tmp/.git. You then go to /tmp/experiment to do something and run some git commands. Easy fix: on boot, have the "rc" script create a root-owned /tmp/.git dummy file with r-------- permissions. Someone can also create a /tmp/foo/.git; but to be susceptible to that, you have to be under /tmp/foo. That's another user's directory. What are you doing in there? Serves you right. If /tmp/foo is your own, and someone planted a .git into it, that's your problem too: you're creating material in /tmp that is accessible to others, which is a security no-no. Probably, this should be fixed in the kernel: the kernel should not allow a regular user to create a hidden directory (i.e. name starting with ".") in /tmp. Or probably any hidden object. Such a fix is more general: it fixes the issue for any git-like program that walks up the tree looking for a special dot directory or file, including all such programs not yet written. The rule could be general, such that creating a hidden object in a directory is only allowed to the directory's owner, not just to anyone who has write permissions to the directory. In other words, if multiple users have write access to a directory, such as /tmp, but any other kind of directory, then they are not allowed to perpetrate hidden objects on each other (both because those things don't show up under "ls" without "-a" and because programs find those and react to them). In fact, I would go one step further and enforce the kernel rule that writing to an existing dot file is denied to anyone other than the owner that file, regardless of its write permissions.