{"thread":{"id":"6156","subject":"Default \"tar\" umask..","startedAt":"2006-12-30T18:45:23Z","lastAt":"2007-01-07T21:28:30Z","messageCount":10,"participants":["Linus Torvalds","Junio C Hamano","René Scharfe","Krzysztof Halasa"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"30505","messageId":"Pine.LNX.4.64.0612301037570.4473@woody.osdl.org","threadId":"6156","inReplyTo":null,"subject":"Default \"tar\" umask..","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-12-30T18:45:23Z","receivedAt":"2006-12-30T18:45:23Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nWe just had a posting on the kernel security list where a person was \nupset that the 2.6.19.1 and .2 tar-files were apparently group and \nworld-writable.\n\nNow, the default kernel releases don't do that (at least any more), \nbecause I've got\n\n\t[tar]\n\t\tumask=022\n\nin my git config file these days, but the stable team apparently doesn't.\n\nLooking at some of the tar-files I have lying around, they all seem to \nhave used that 022 umask, and maybe we should just change the git default \nto that?\n\nAnybody who wants to, can get the zero umask by just using the config \nfile, but maybe the default should be the common case, and the case that \nisn't as likely to be a security issue if you untar it.\n\nGNU tar has a \"--no-same-permissions\" flag to use the user umask at untar \ntime, but I think that's a GNU-tar specific feature (at least I can't see \nany short flag to do the same), and I have to admit that I've _never_ used \nit even though I've used \"tar\" a long time, so at least going by my \npersonal experience, I'd say it's very uncommon for people to use it.\n\nThe trivial untested patch below should do it.\n\n\t\tLinus\n\n---\ndiff --git a/archive-tar.c b/archive-tar.c\nindex af47fdc..d4a2fa4 100644\n--- a/archive-tar.c\n+++ b/archive-tar.c\n@@ -15,7 +15,7 @@ static char block[BLOCKSIZE];\n static unsigned long offset;\n \n static time_t archive_time;\n-static int tar_umask;\n+static int tar_umask = 022;\n static int verbose;\n \n /* writes out the whole block, but only if it is full */\n"},{"id":"30510","messageId":"7vfyaxjiaj.fsf@assigned-by-dhcp.cox.net","threadId":"6156","inReplyTo":"Pine.LNX.4.64.0612301037570.4473@woody.osdl.org","subject":"Re: Default \"tar\" umask..","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-30T19:27:32Z","receivedAt":"2006-12-30T19:27:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> We just had a posting on the kernel security list where a person was \n> upset that the 2.6.19.1 and .2 tar-files were apparently group and \n> world-writable.\n\nI had an impression that this is only an issue when you untar as\nroot, and running 'tar xf' as root _is_ a more serious security\nissue than whatever permission the tar archive itself records.\n\nHaving said that, I do not see much reason for anybody to want\nto extract any material that is worth to be placed under version\ncontrol in a way that is world-writable, so I do not mind having\n002 as the default, but I feel that group-writability should be\nkept under control of the umask of end users who know what they\nare doing.\n\nHistorically we used to have 022 as the default, and IIRC we\nloosened it exactly because some people hated that we created\nfiles and directories closed to group members.\n"},{"id":"30901","messageId":"459EB78B.60000@lsrfire.ath.cx","threadId":"6156","inReplyTo":"7vfyaxjiaj.fsf@assigned-by-dhcp.cox.net","subject":"Re: Default \"tar\" umask..","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2007-01-05T20:39:39Z","receivedAt":"2007-01-05T20:39:39Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Junio C Hamano schrieb:\n> Linus Torvalds writes:\n> \n>> We just had a posting on the kernel security list where a person\n>> was upset that the 2.6.19.1 and .2 tar-files were apparently group\n>> and world-writable.\n> \n> I had an impression that this is only an issue when you untar as \n> root, and running 'tar xf' as root _is_ a more serious security issue\n> than whatever permission the tar archive itself records.\n\nWhile I agree, I also detect a theory-practice-mismatch. Users,\noperating as root, can (and apparently often do) download a tar file\nreleased by a free software project and untar it with the implied -p\noption *without* getting hurt. Most of the time they simply trust\nthe file contents (who checks all source files after download?), so\nwhy shouldn't they trust the file permissions, too?\n\nSo while it's not the smartest thing to do, it clearly is happening.\nAnd perhaps we should not be the ones trying to educate the users of\nsoftware made by _our_ users on the safety of tar by defaulting to loose\npermissions.\n\nLet's be \"safe by default\", even if that particular definition of \"safe\"\nmeans \"a bit safer, but only if the untarring is done in a very unsafe\nway\". ;-)\n\n> Having said that, I do not see much reason for anybody to want to\n> extract any material that is worth to be placed under version control\n> in a way that is world-writable, so I do not mind having 002 as the\n> default, but I feel that group-writability should be kept under\n> control of the umask of end users who know what they are doing.\n\nYes, using 002 is tempting. But it's got the same \"looseness\" problems\nas 000, only on a smaller scaler: there are certainly situations where a\nuser doesn't want to share write permissions with all the members of her\ncurrent group. If we change the default, let's go all the way to 022.\n\n> Historically we used to have 022 as the default, and IIRC we loosened\n> it exactly because some people hated that we created files and\n> directories closed to group members.\n\nThe situation has changed a bit in that we don't need to find one mask\nthat fits all users -- we only need to find a default value for the\nconfig option tar.umask now. If a project is unhappy with that value,\nit can easily change it back to zero or to a different value.\n\nAdmittedly, that doesn't help users who download from a \"022\" project,\nbut really want something looser. I think it's more important to\navoid violating the expectations of all those who freak out at 0666\npermission modes attached to their freshly downloaded files, though.\n\nTrivial patch follows.\n\nRené\n\n\ndiff --git a/archive-tar.c b/archive-tar.c\nindex af47fdc..ae84bcb 100644\n--- a/archive-tar.c\n+++ b/archive-tar.c\n@@ -15,7 +15,7 @@ static char block[BLOCKSIZE];\n static unsigned long offset;\n \n static time_t archive_time;\n-static int tar_umask;\n+static int tar_umask = 0022;\n static int verbose;\n \n /* writes out the whole block, but only if it is full */\n"},{"id":"30904","messageId":"7vzm8xdw3t.fsf@assigned-by-dhcp.cox.net","threadId":"6156","inReplyTo":"459EB78B.60000@lsrfire.ath.cx","subject":"Re: Default \"tar\" umask..","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-05T21:03:50Z","receivedAt":"2007-01-05T21:03:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"René Scharfe writes:\n\n> Junio C Hamano schrieb:\n>> ...\n>> Having said that, I do not see much reason for anybody to want to\n>> extract any material that is worth to be placed under version control\n>> in a way that is world-writable, so I do not mind having 002 as the\n>> default, but I feel that group-writability should be kept under\n>> control of the umask of end users who know what they are doing.\n>\n> Yes, using 002 is tempting. But it's got the same \"looseness\" problems\n> as 000, only on a smaller scaler: there are certainly situations where a\n> user doesn't want to share write permissions with all the members of her\n> current group. If we change the default, let's go all the way to 022.\n\nI don't think the above argument makes much sense -- it does not\nexplain why you do not go \"all the way\" to 077.\n\nOn the other hand, I can explain 002 fairly easily and\nconsistently. This matters only for users who can become root\nand does not know or care about implied -p, and the group root\nbelongs to had better not contain any suspicious user, so\nleaving group open does not hurt. 022 actively hurts sane usage\n(i.e. work always with a sane umask and extract as non root\nusers) while 002 does not.\n\n> Admittedly, that doesn't help users who download from a \"022\" project,\n> but really want something looser. I think it's more important to\n> avoid violating the expectations of all those who freak out at 0666\n> permission modes attached to their freshly downloaded files, though.\n\nExactly, and that is why I think 002 is much saner.\n"},{"id":"30910","messageId":"Pine.LNX.4.64.0701051336000.3661@woody.osdl.org","threadId":"6156","inReplyTo":"7vzm8xdw3t.fsf@assigned-by-dhcp.cox.net","subject":"Re: Default \"tar\" umask..","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2007-01-05T21:40:38Z","receivedAt":"2007-01-05T21:40:38Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 5 Jan 2007, Junio C Hamano wrote:\n> >\n> > Yes, using 002 is tempting. But it's got the same \"looseness\" problems\n> > as 000, only on a smaller scaler: there are certainly situations where a\n> > user doesn't want to share write permissions with all the members of her\n> > current group. If we change the default, let's go all the way to 022.\n> \n> I don't think the above argument makes much sense -- it does not\n> explain why you do not go \"all the way\" to 077.\n\nI really think that 022 is the right choice, for a very simple reason: \npeoples expectations. It's just _common_.\n\n> On the other hand, I can explain 002 fairly easily and\n> consistently.\n\nNo you can't. 002 makes no sense at all in a very common old-fashioned \nsetup with a \"user\" group. \n\nMaybe I'm old, and these days most setups seem to give people their own \ngroup (so I'm \"torvalds:torvalds\" on all the machines I have access to), \nbut it used to be _very_ common to have just a \"user\" group that all \nnormal users were part of (or have the default gid depend on something \nlike which department you are in).\n\nIn that situation, 002 is really effectively no different at all from 000.\n\nWhich is why 022 is the historical default for umask. \n\n022 really is very easy to explain: \"readability (and executability) is a \nlot less dangerous than writability, and by default we only give \nwritability to the user\". That's why we _don't_ commonly have 066 or 077 \nas the umask, and also why 002 is the default umask ONLY on systems where \nusers have their own individual groups by default.\n\n\t\tLinus\n"},{"id":"30912","messageId":"7vmz4xdssh.fsf@assigned-by-dhcp.cox.net","threadId":"6156","inReplyTo":"Pine.LNX.4.64.0701051336000.3661@woody.osdl.org","subject":"Re: Default \"tar\" umask..","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-05T22:15:26Z","receivedAt":"2007-01-05T22:15:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Fri, 5 Jan 2007, Junio C Hamano wrote:\n>> ...\n>> On the other hand, I can explain 002 fairly easily and\n>> consistently.\n>\n> No you can't. 002 makes no sense at all in a very common old-fashioned \n> setup with a \"user\" group. \n\nI do not think so (see below).\n\n> Maybe I'm old, and these days most setups seem to give people their own \n> group (so I'm \"torvalds:torvalds\" on all the machines I have access to), \n> but it used to be _very_ common to have just a \"user\" group that all \n> normal users were part of (or have the default gid depend on something \n> like which department you are in).\n>\n> In that situation, 002 is really effectively no different at all from 000.\n\nI remember those days. People had 022 umask for that exact\nreason, as you said, in such a setup. It was quite common. On\nthe other hand, modern setups often use \"own\" group and people\noften use 002 umask.\n\nIf you extract as a normal user (i.e. without -p) then 002 is\nreally effectively no different at all from 000 because umask\nkicks in and give the results the user would expect in either\nsetups, which is good. In \"user\" group setup, umask 022 makes\nfiles to 0644, in \"own\" group setup, umask 002 makes files to\n0664. All is good. If the archive is made with 022, that would\nbreak expectation of users whose umask is 002 (a sane value in\nmodern \"own\" group setups).\n\nThe current 000 was bad for users who work as root and do not\nknow about implied -p (which is not their fault). When\nextracting as root, the files and directories are owned by\n'root' and its group.\n\nEven in the old \"user\" group setups, I _thought_ the root was in\nhis own group or wheel in BSD, and the group was not shared with\nJoe Random users, so if that is the case, group writability is\nnot an problem. In the modern \"own\" group setups, the root user\nis in its own his group 'root', so group writability is not an\nissue either.\n\n> 022 really is very easy to explain: \"readability (and executability) is a \n> lot less dangerous than writability, and by default we only give \n> writability to the user\". That's why we _don't_ commonly have 066 or 077 \n> as the umask, and also why 002 is the default umask ONLY on systems where \n> users have their own individual groups by default.\n\n077 was a tongue-in-cheek comment.\n\nI think we are basing our reasoning with the same shared\nunderstanding of historical practice of \"user\" group. I wonder\nwhy the differenece in conclusions.\n\nMaybe my recollection of historical practice was faulty and the\nroot shared its group with Joe Random users? If so, I would\nagree that 002 makes no sense at all, as you said.\n"},{"id":"30914","messageId":"459ED17E.2080101@lsrfire.ath.cx","threadId":"6156","inReplyTo":"7vzm8xdw3t.fsf@assigned-by-dhcp.cox.net","subject":"Re: Default \"tar\" umask..","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2007-01-05T22:30:22Z","receivedAt":"2007-01-05T22:30:22Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"[Junio: Sorry for resending, I somehow dropped the CC:'s the first time.]\n\nJunio C Hamano schrieb:\n>>> >>> Having said that, I do not see much reason for anybody to want to\n>>> >>> extract any material that is worth to be placed under version\n>>> >>> control in a way that is world-writable, so I do not mind having\n>>> >>> 002 as the default, but I feel that group-writability should be\n>>> >>> kept under control of the umask of end users who know what they\n>>> >>> are doing.\n>> >> Yes, using 002 is tempting. But it's got the same \"looseness\"\n>> >> problems as 000, only on a smaller scaler: there are certainly\n>> >> situations where a user doesn't want to share write permissions\n>> >> with all the members of her current group. If we change the\n>> >> default, let's go all the way to 022.\n> > \n> > I don't think the above argument makes much sense -- it does not \n> > explain why you do not go \"all the way\" to 077.\n\nWell, what I had in mind were free software projects and simple users,\ni.e. publicly hosted tar files and users that only download and extract\nthem, and then don't add confidential changes afterwards. You're right,\nof course: why stop there? 077 would be safest. :->\n\n> > On the other hand, I can explain 002 fairly easily and consistently.\n> > This matters only for users who can become root and does not know or\n> > care about implied -p, and the group root belongs to had better not\n> > contain any suspicious user, so leaving group open does not hurt.\n> > 022 actively hurts sane usage (i.e. work always with a sane umask and\n> > extract as non root users) while 002 does not.\n\nHm, right, I was not thinking straight -- I didn't see that the gid of\nthe extracted files will be set to 0 by tar (as specified in our tar\nfiles). Err, unless the target system has a group named git, which\nwould then be used instead. Come to think of it, having this \"git\"\ngroup name in there is a bit strange and unnecessary. How about the\nfollowing patch?\n\n\nIn order to make the generated tar files more friendly to users who\nextract them as root using GNU tar and its implied -p option, change\nthe default umask to 002 and change the owner name and group name to\nroot. This ensures that a) the extracted files and directories are\nnot world-writable and b) that they belong to user and group root.\n\nBefore they would have been assigned to a user and/or group named\ngit if it existed. This also answers the question in the removed\ncomment: uid=0, gid=0, uname=root, gname=root is exactly what we\nwant.\n\nNormal users who let tar apply their umask while extracting are\nonly affected if their umask allowed the world to change their\nfiles (e.g. a umask of zero). This case is so unlikely and strange\nthat we don't need to support it.\n\nCredit goes to Junio for finding the ideal default umask of 002\nthrough sheer logic.\n\nSigned-off-by: Rene Scharfe \n\n---\n archive-tar.c | 7 +++----\n 1 files changed, 3 insertions(+), 4 deletions(-)\n\ndiff --git a/archive-tar.c b/archive-tar.c\nindex af47fdc..7d52a06 100644\n--- a/archive-tar.c\n+++ b/archive-tar.c\n@@ -15,7 +15,7 @@ static char block[BLOCKSIZE];\n static unsigned long offset;\n \n static time_t archive_time;\n-static int tar_umask;\n+static int tar_umask = 002;\n static int verbose;\n \n /* writes out the whole block, but only if it is full */\n@@ -210,11 +210,10 @@ static void write_entry(const unsigned char *sha1, struct strbuf *path,\n \tsprintf(header.size, \"%011lo\", S_ISREG(mode) ? size : 0);\n \tsprintf(header.mtime, \"%011lo\", archive_time);\n \n-\t/* XXX: should we provide more meaningful info here? */\n \tsprintf(header.uid, \"%07o\", 0);\n \tsprintf(header.gid, \"%07o\", 0);\n-\tstrlcpy(header.uname, \"git\", sizeof(header.uname));\n-\tstrlcpy(header.gname, \"git\", sizeof(header.gname));\n+\tstrlcpy(header.uname, \"root\", sizeof(header.uname));\n+\tstrlcpy(header.gname, \"root\", sizeof(header.gname));\n \tsprintf(header.devmajor, \"%07o\", 0);\n \tsprintf(header.devminor, \"%07o\", 0);\n \n"},{"id":"30917","messageId":"7vejq9drlx.fsf@assigned-by-dhcp.cox.net","threadId":"6156","inReplyTo":"459ED17E.2080101@lsrfire.ath.cx","subject":"Re: Default \"tar\" umask..","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-05T22:40:58Z","receivedAt":"2007-01-05T22:40:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"René Scharfe writes:\n\n> [Junio: Sorry for resending, I somehow dropped the CC:'s the first time.]\n\nI think that was my fault. I somehow dropped the CC:'s and\nresent without you to the list, and you responded to the first\none.\n\n> ... Err, unless the target system has a group named git, which\n> would then be used instead. Come to think of it, having this \"git\"\n> group name in there is a bit strange and unnecessary. How about the\n> following patch?\n\nIt is a very good point. I think this patch is sane, regardless\nof 002 vs 022 issue.\n"},{"id":"31055","messageId":"m3irfizwvv.fsf@defiant.localdomain","threadId":"6156","inReplyTo":"7vmz4xdssh.fsf@assigned-by-dhcp.cox.net","subject":"Re: Default \"tar\" umask..","fromName":"Krzysztof Halasa","fromEmail":"khc@pm.waw.pl","sentAt":"2007-01-07T15:20:36Z","receivedAt":"2007-01-07T15:20:36Z","isPatch":false,"sender":{"key":"khc@pm.waw.pl","avatar":null},"body":"Junio C Hamano writes:\n\n> If the archive is made with 022, that would\n> break expectation of users whose umask is 002 (a sane value in\n> modern \"own\" group setups).\n\nWhat exactly do they expect from 002? That root group will be able\nto write to the files?\n\n002 umasks and per-user groups were created, IIRC, purely as as ACL\nsubstitute. I wonder how many people really need anything like\nthat, especially human people (not news.news things and root.uucp\n/dev/ttyS*). I guess not very many.\n-- \nKrzysztof Halasa\n"},{"id":"31081","messageId":"7v8xge1q81.fsf@assigned-by-dhcp.cox.net","threadId":"6156","inReplyTo":"m3irfizwvv.fsf@defiant.localdomain","subject":"Re: Default \"tar\" umask..","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-07T21:28:30Z","receivedAt":"2007-01-07T21:28:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Krzysztof Halasa writes:\n\n> Junio C Hamano writes:\n>\n>> If the archive is made with 022, that would\n>> break expectation of users whose umask is 002 (a sane value in\n>> modern \"own\" group setups).\n>\n> What exactly do they expect from 002? That root group will be able\n> to write to the files?\n\nIt is more like \"no suspicious individual would not be able to\nwrite to them\". You could always tell tar to honor your umask\nwhile extracting as root and have 022 or a tighter umask if you\nhave somebody untrustworthy in your 'root' group.\n\nAnd in mordern setup, umask 002 makes tons of sense. My primary\ngroup is 'junio' in modern setup, but I belong to secondary\ngroups like 'git' and 'mix' that are shared with other people\nwho work on 'git' and 'mix' projects. umask 002 is the natural\nthing to use from log-in and never change.\n\nMy home directory is owned by junio.junio and has mode 2775.\nOnly I can create a new file or a directory there, and result of\ndoing so is owned by junio.junio and has 0664 or 0775 which\nmeans only I can write to it.\n\nA directory used by 'git' project is owned by .git\nwhere that is from the git group and has mode 2775.\nOnly the project members of 'git', who shared the 'git' group\nwith me, can create a new file or a directory there, and result\nof doing so is owned by .git where is the project\nmember who is doing so, and has 0664 or 0775 which means only\nthe project members of 'git' can write to it.\n"}]}