Re: Default "tar" umask..

["René Scharfe" <rene.scharfe@lsrfire.ath.cx>]

[Junio: Sorry for resending, I somehow dropped the CC:'s the first time.]

Junio C Hamano schrieb:
>>> >>> Having said that, I do not see much reason for anybody to want to
>>> >>>  extract any material that is worth to be placed under version
>>> >>> control in a way that is world-writable, so I do not mind having
>>> >>> 002 as the default, but I feel that group-writability should be
>>> >>> kept under control of the umask of end users who know what they
>>> >>> are doing.
>> >> Yes, using 002 is tempting.  But it's got the same "looseness"
>> >> problems as 000, only on a smaller scaler: there are certainly
>> >> situations where a user doesn't want to share write permissions
>> >> with all the members of her current group.  If we change the
>> >> default, let's go all the way to 022.
> > 
> > I don't think the above argument makes much sense -- it does not 
> > explain why you do not go "all the way" to 077.

Well, what I had in mind were free software projects and simple users,
i.e. publicly hosted tar files and users that only download and extract
them, and then don't add confidential changes afterwards.  You're right,
of course: why stop there?  077 would be safest. :->

> > On the other hand, I can explain 002 fairly easily and consistently.
> > This matters only for users who can become root and does not know or
> > care about implied -p, and the group root belongs to had better not
> > contain any suspicious user, so leaving group open does not hurt.
> > 022 actively hurts sane usage (i.e. work always with a sane umask and
> > extract as non root users) while 002 does not.

Hm, right, I was not thinking straight -- I didn't see that the gid of
the extracted files will be set to 0 by tar (as specified in our tar
files).  Err, unless the target system has a group named git, which
would then be used instead.  Come to think of it, having this "git"
group name in there is a bit strange and unnecessary.  How about the
following patch?


In order to make the generated tar files more friendly to users who
extract them as root using GNU tar and its implied -p option, change
the default umask to 002 and change the owner name and group name to
root.  This ensures that a) the extracted files and directories are
not world-writable and b) that they belong to user and group root.

Before they would have been assigned to a user and/or group named
git if it existed.  This also answers the question in the removed
comment: uid=0, gid=0, uname=root, gname=root is exactly what we
want.

Normal users who let tar apply their umask while extracting are
only affected if their umask allowed the world to change their
files (e.g. a umask of zero).  This case is so unlikely and strange
that we don't need to support it.

Credit goes to Junio for finding the ideal default umask of 002
through sheer logic.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>

---
 archive-tar.c |    7 +++----
 1 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/archive-tar.c b/archive-tar.c
index af47fdc..7d52a06 100644
--- a/archive-tar.c
+++ b/archive-tar.c
@@ -15,7 +15,7 @@ static char block[BLOCKSIZE];
 static unsigned long offset;
 
 static time_t archive_time;
-static int tar_umask;
+static int tar_umask = 002;
 static int verbose;
 
 /* writes out the whole block, but only if it is full */
@@ -210,11 +210,10 @@ static void write_entry(const unsigned char *sha1, struct strbuf *path,
 	sprintf(header.size, "%011lo", S_ISREG(mode) ? size : 0);
 	sprintf(header.mtime, "%011lo", archive_time);
 
-	/* XXX: should we provide more meaningful info here? */
 	sprintf(header.uid, "%07o", 0);
 	sprintf(header.gid, "%07o", 0);
-	strlcpy(header.uname, "git", sizeof(header.uname));
-	strlcpy(header.gname, "git", sizeof(header.gname));
+	strlcpy(header.uname, "root", sizeof(header.uname));
+	strlcpy(header.gname, "root", sizeof(header.gname));
 	sprintf(header.devmajor, "%07o", 0);
 	sprintf(header.devminor, "%07o", 0);