Default "tar" umask..

Default "tar" umask..

[Linus Torvalds]

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 */

Re: Default "tar" umask..

[Junio C Hamano]

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.

Re: Default "tar" umask..

[René Scharfe]

Junio C Hamano schrieb:
> 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". ;-)

> 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 */

Re: Default "tar" umask..

[Junio C Hamano]

René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:

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

Re: Default "tar" umask..

[Linus Torvalds]

On Fri, 5 Jan 2007, Junio C Hamano wrote:
> >
> > 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

Re: Default "tar" umask..

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

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

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

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

Re: Default "tar" umask..

[Krzysztof Halasa]

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

Re: Default "tar" umask..

[Junio C Hamano]

Krzysztof Halasa <khc@pm.waw.pl> writes:

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

Re: Default "tar" umask..

[René Scharfe]

[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);
 

Re: Default "tar" umask..

[Junio C Hamano]

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.