Junio C Hamano schrieb: > Linus Torvalds <torvalds@xxxxxxxx> 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 */ - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html