threads / discuss / 6156

Default "tar" umask..

Subject: Default "tar" umask..

## tl;dr

10 messages between Dec 30, 2006 and Jan 7, 2007.

replies: 9people: 4as markdown or json

Linus Torvalds· Dec 30, 2006, 18:45 UTC · lore

We just had a posting on the kernel security list where a person was upset that the 2.6.19.1 and .2 tar-files were apparently group and world-writable.

Now, the default kernel releases don't do that (at least any more), because I've got

	[tar]
		umask=022
in my git config file these days, but the stable team apparently doesn't.

Looking at some of the tar-files I have lying around, they all seem to have used that 022 umask, and maybe we should just change the git default to that?

Anybody who wants to, can get the zero umask by just using the config file, but maybe the default should be the common case, and the case that isn't as likely to be a security issue if you untar it.

GNU tar has a "--no-same-permissions" flag to use the user umask at untar time, but I think that's a GNU-tar specific feature (at least I can't see any short flag to do the same), and I have to admit that I've _never_ used it even though I've used "tar" a long time, so at least going by my personal experience, I'd say it's very uncommon for people to use it.

The trivial untested patch below should do it.
		Linus
---
diff --git a/archive-tar.c b/archive-tar.c
index af47fdc..d4a2fa4 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 = 022;
 static int verbose;
 
 /* writes out the whole block, but only if it is full */
Junio C Hamano· Dec 30, 2006, 19:27 UTC · re: Linus Torvalds · lore

Re: Default "tar" umask..

Linus Torvalds <torvalds@osdl.org> writes:
> We just had a posting on the kernel security list where a person was 
> upset that the 2.6.19.1 and .2 tar-files were apparently group and 
> world-writable.

I had an impression that this is only an issue when you untar as root, and running 'tar xf' as root _is_ a more serious security issue than whatever permission the tar archive itself records.

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.

Historically we used to have 022 as the default, and IIRC we loosened it exactly because some people hated that we created files and directories closed to group members.

René Scharfe· Jan 5, 2007, 20:39 UTC · re: Junio C Hamano · lore

Re: Default "tar" umask..

Junio C Hamano schrieb:
Show 9 quoted lines
> Linus Torvalds <torvalds@osdl.org> writes:
> 
>> We just had a posting on the kernel security list where a person
>> was upset that the 2.6.19.1 and .2 tar-files were apparently group
>> and world-writable.
> 
> I had an impression that this is only an issue when you untar as 
> root, and running 'tar xf' as root _is_ a more serious security issue
> than whatever permission the tar archive itself records.

While I agree, I also detect a theory-practice-mismatch. Users, operating as root, can (and apparently often do) download a tar file released by a free software project and untar it with the implied -p option *without* getting hurt. Most of the time they simply trust the file contents (who checks all source files after download?), so why shouldn't they trust the file permissions, too?

So while it's not the smartest thing to do, it clearly is happening. And perhaps we should not be the ones trying to educate the users of software made by _our_ users on the safety of tar by defaulting to loose permissions.

Let's be "safe by default", even if that particular definition of "safe" means "a bit safer, but only if the untarring is done in a very unsafe way". ;-)

Show 5 quoted lines
> 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.

> Historically we used to have 022 as the default, and IIRC we loosened
> it exactly because some people hated that we created files and
> directories closed to group members.

The situation has changed a bit in that we don't need to find one mask that fits all users -- we only need to find a default value for the config option tar.umask now. If a project is unhappy with that value, it can easily change it back to zero or to a different value.

Admittedly, that doesn't help users who download from a "022" project, but really want something looser. I think it's more important to avoid violating the expectations of all those who freak out at 0666 permission modes attached to their freshly downloaded files, though.

Trivial patch follows.
René
diff --git a/archive-tar.c b/archive-tar.c
index af47fdc..ae84bcb 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 = 0022;
 static int verbose;
 
 /* writes out the whole block, but only if it is full */
Junio C Hamano· Jan 5, 2007, 21:03 UTC · re: René Scharfe · lore

Re: Default "tar" umask..

René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
Show 12 quoted lines
> 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.

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.

> Admittedly, that doesn't help users who download from a "022" project,
> but really want something looser.  I think it's more important to
> avoid violating the expectations of all those who freak out at 0666
> permission modes attached to their freshly downloaded files, though.
Exactly, and that is why I think 002 is much saner.
Linus Torvalds· Jan 5, 2007, 21:40 UTC · re: Junio C Hamano · lore

Re: Default "tar" umask..

On Fri, 5 Jan 2007, Junio C Hamano wrote:
Show 8 quoted lines
> >
> > 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.

I really think that 022 is the right choice, for a very simple reason: peoples expectations. It's just _common_.

> On the other hand, I can explain 002 fairly easily and
> consistently.

No you can't. 002 makes no sense at all in a very common old-fashioned setup with a "user" group.

Maybe I'm old, and these days most setups seem to give people their own group (so I'm "torvalds:torvalds" on all the machines I have access to), but it used to be _very_ common to have just a "user" group that all normal users were part of (or have the default gid depend on something like which department you are in).

In that situation, 002 is really effectively no different at all from 000.
Which is why 022 is the historical default for umask. 

022 really is very easy to explain: "readability (and executability) is a lot less dangerous than writability, and by default we only give writability to the user". That's why we _don't_ commonly have 066 or 077 as the umask, and also why 002 is the default umask ONLY on systems where users have their own individual groups by default.

		Linus
Junio C Hamano· Jan 5, 2007, 22:15 UTC · re: Linus Torvalds · lore

Re: Default "tar" umask..

Linus Torvalds <torvalds@osdl.org> writes:
Show 7 quoted lines
> On Fri, 5 Jan 2007, Junio C Hamano wrote:
>> ...
>> On the other hand, I can explain 002 fairly easily and
>> consistently.
>
> No you can't. 002 makes no sense at all in a very common old-fashioned 
> setup with a "user" group. 
I do not think so (see below).
Show 7 quoted lines
> Maybe I'm old, and these days most setups seem to give people their own 
> group (so I'm "torvalds:torvalds" on all the machines I have access to), 
> but it used to be _very_ common to have just a "user" group that all 
> normal users were part of (or have the default gid depend on something 
> like which department you are in).
>
> In that situation, 002 is really effectively no different at all from 000.

I remember those days. People had 022 umask for that exact reason, as you said, in such a setup. It was quite common. On the other hand, modern setups often use "own" group and people often use 002 umask.

If you extract as a normal user (i.e. without -p) then 002 is
really effectively no different at all from 000 because umask
kicks in and give the results the user would expect in either
setups, which is good.  In "user" group setup, umask 022 makes
files to 0644, in "own" group setup, umask 002 makes files to
0664.  All is good.  If the archive is made with 022, that would
break expectation of users whose umask is 002 (a sane value in
modern "own" group setups).

The current 000 was bad for users who work as root and do not know about implied -p (which is not their fault). When extracting as root, the files and directories are owned by 'root' and its group.

Even in the old "user" group setups, I _thought_ the root was in his own group or wheel in BSD, and the group was not shared with Joe Random users, so if that is the case, group writability is not an problem. In the modern "own" group setups, the root user is in its own his group 'root', so group writability is not an issue either.

Show 5 quoted lines
> 022 really is very easy to explain: "readability (and executability) is a 
> lot less dangerous than writability, and by default we only give 
> writability to the user". That's why we _don't_ commonly have 066 or 077 
> as the umask, and also why 002 is the default umask ONLY on systems where 
> users have their own individual groups by default.
077 was a tongue-in-cheek comment.

I think we are basing our reasoning with the same shared understanding of historical practice of "user" group. I wonder why the differenece in conclusions.

Maybe my recollection of historical practice was faulty and the root shared its group with Joe Random users? If so, I would agree that 002 makes no sense at all, as you said.

Krzysztof Halasa· Jan 7, 2007, 15:20 UTC · re: Junio C Hamano · lore

Re: Default "tar" umask..

Junio C Hamano <junkio@cox.net> writes:
> If the archive is made with 022, that would
> break expectation of users whose umask is 002 (a sane value in
> modern "own" group setups).

What exactly do they expect from 002? That root group will be able to write to the files?

002 umasks and per-user groups were created, IIRC, purely as as ACL substitute. I wonder how many people really need anything like that, especially human people (not news.news things and root.uucp /dev/ttyS*). I guess not very many.

-- 
Krzysztof Halasa
Junio C Hamano· Jan 7, 2007, 21:28 UTC · re: Krzysztof Halasa · lore

Re: Default "tar" umask..

Krzysztof Halasa <khc@pm.waw.pl> writes:
Show 8 quoted lines
> Junio C Hamano <junkio@cox.net> writes:
>
>> If the archive is made with 022, that would
>> break expectation of users whose umask is 002 (a sane value in
>> modern "own" group setups).
>
> What exactly do they expect from 002? That root group will be able
> to write to the files?

It is more like "no suspicious individual would not be able to write to them". You could always tell tar to honor your umask while extracting as root and have 022 or a tighter umask if you have somebody untrustworthy in your 'root' group.

And in mordern setup, umask 002 makes tons of sense. My primary group is 'junio' in modern setup, but I belong to secondary groups like 'git' and 'mix' that are shared with other people who work on 'git' and 'mix' projects. umask 002 is the natural thing to use from log-in and never change.

My home directory is owned by junio.junio and has mode 2775. Only I can create a new file or a directory there, and result of doing so is owned by junio.junio and has 0664 or 0775 which means only I can write to it.

A directory used by 'git' project is owned by <somebody>.git where that <somebody> is from the git group and has mode 2775. Only the project members of 'git', who shared the 'git' group with me, can create a new file or a directory there, and result of doing so is owned by <user>.git where <user> is the project member who is doing so, and has 0664 or 0775 which means only the project members of 'git' can write to it.

René Scharfe· Jan 5, 2007, 22:30 UTC · re: Junio C Hamano · lore

Re: Default "tar" umask..

[Junio: Sorry for resending, I somehow dropped the CC:'s the first time.]
Junio C Hamano schrieb:
Show 14 quoted lines
>>> >>> 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. :->

Show 6 quoted lines
> > 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);
 
Junio C Hamano· Jan 5, 2007, 22:40 UTC · re: René Scharfe · lore

Re: Default "tar" umask..

René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> [Junio: Sorry for resending, I somehow dropped the CC:'s the first time.]

I think that was my fault. I somehow dropped the CC:'s and resent without you to the list, and you responded to the first one.

> ...  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?

It is a very good point. I think this patch is sane, regardless of 002 vs 022 issue.

← back to recent threads