Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> > We do not track permissions of directories at all. >> >> Ok, this seems like something that should be done as well, even if we >> can stipulate at first that a directory should have rwx for the user >> in question if you hope to track it. > > No, no, no. It should not be tracked. It is the responsibility of the > _user_ to set it to something sane, be that by a umask or by sticky > groups, or by setting the permissions of the parent directory. > > It is _nothing_ we want to put into the repository. That is the _wrong_ > place to put it. I'm not sure it's wrong to be able to track permissions, but it's definitely wrong to track them by default. GNU Arch had some permission tracking, and I got hit by it several times. You have several things you might have wanted to track: * read/write for the user. But I can't imagine a case where you wouldn't want to be able to read and write your own files. * permissions for group. But that doesn't make any sense when several persons work on the same project, and don't share the same /etc/group. * permissions for others. But that, again, doesn't make sense when several persons work on the same project with different setups. I sometimes work at home, where I'm basically the only user, I don't care at all about permissions for others. At work, it's totally different, since it's a big NFS shared by all the lab. And I might very well disclose my work to the rest of the lab, and work with someone who do not want to do so. * Execute bit. This one is relevant. Indeed, it's more a kind of metadata than really a permission (you can still execute the file with /lib/ld-linux.so.2 /path/to/file or such kind of things). Using GNU Arch, I got the cases in real life of a project in which some files had group read permission, some other not, because they were created by developers having different umask. Worse than this, I got some group-writable files in my $HOME without noticing it, which is basically a security hole. -- Matthieu - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
