Re: Honor extractor's umask in git-tar-tree.

On Mon, 3 Oct 2005, H. Peter Anvin wrote:

If the old-format (with random write bits) is out of circulation -- which I
can't tell for sure they it is, but Linus' kernel tree doesn't seem to have
any of these objects

Oh, it does.

Run "git-fsck-cache --full --strict", and you'll get several trees that 
the strict checker marks as bad. I think it's mostly all one entry, namely 
arch/i386/kernel/vsyscall-note.S being marked 0664.

Git itself has even more of them - the kernel actually has fewer, because 
most work was done with a consistent umask of 022 (ie mostly mine), and by 
the time others started using git actively, we'd already changed the git 
rules.

However, there's nothing that says that we couldn't use one more bit in 
the "mode" flag to just say "this is an _exact_ mode, please preserve it". 
A kind of "sticky mode" for git. We've got _bits_ plenty: it's an ASCII 
text-mode representation in the trees (infinite bits), and even in the 
index it's a 32-bit thing that we only use 12 bits of (9 bits for 
permissions, 3 bits for the sparsely represented directory/symlink/regular 
file)

We'd have to be a bit careful to preserve that bit when doing an index 
refresh, but it's really not very hard. The hardest part is actually doing 
so for directories, since we don't keep the directories in the index at 
_all_.

But the fact is, it wouldn't solve the git-tar-tree thing. We can 
_represent_ exact masks, but we don't _want_ to, because normally it just 
leads to horrible problems with different people having different umasks. 
So in order to avoid having mode change merges, we'd _still_ have to make 
the current "0666/0777 + umask" be the normal one, and you'd use this 
"exact mode" thing only for very special cases (ie for backing up your 
home directory or similar, _not: for a distributed SCM).

As to tar: I think the current

        if (S_ISDIR(mode) || S_ISREG(mode))
                mode |= (mode & 0100) ? 0777 : 0666;

is wrong. It makes things world-writable by default, and that's just 
dangerous. "tar" normally won't apply umask when untarring (there's a flag 
for it, but I have never ever used it myself, and I doubt anybody else 
really does either - it's called "--no-same-permissions" in GNU tar).

I think a "0775" or "0664" might be acceptable (an umask of 002 is at 
least _normal_), but I suspect 0755/0644 is really better. Doing a simple 

	chmod -R +w

afterwards is better (and takes umask into account) than a "chmod -R o-w", 
since the latter leaves the tree writable for a while.

Ie default permissions are better off being too strict than too lax. Basic 
security.

Of course, if we were to add the "exact mode" bit, then git-tar-tree 
should obviously honor that for any files that have that bit set.

		Linus