git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>
To: Junio C Hamano <junkio@cox.net>
Cc: Linus Torvalds <torvalds@osdl.org>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: Default "tar" umask..
Date: Fri, 05 Jan 2007 21:39:39 +0100	[thread overview]
Message-ID: <459EB78B.60000@lsrfire.ath.cx> (raw)
In-Reply-To: <7vfyaxjiaj.fsf@assigned-by-dhcp.cox.net>

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

  reply	other threads:[~2007-01-05 20:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-30 18:45 Default "tar" umask Linus Torvalds
2006-12-30 19:27 ` Junio C Hamano
2007-01-05 20:39   ` René Scharfe [this message]
2007-01-05 21:03     ` Junio C Hamano
2007-01-05 21:40       ` Linus Torvalds
2007-01-05 22:15         ` Junio C Hamano
2007-01-07 15:20           ` Krzysztof Halasa
2007-01-07 21:28             ` Junio C Hamano
2007-01-05 22:30       ` René Scharfe
2007-01-05 22:40         ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=459EB78B.60000@lsrfire.ath.cx \
    --to=rene.scharfe@lsrfire.ath.cx \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).