{"thread":{"id":"57785","subject":"a problem with git describe","startedAt":"2022-04-23T09:18:35Z","lastAt":"2022-04-26T17:17:15Z","messageCount":23,"participants":["Guy Maurel","Philip Oakley","Junio C Hamano","Carlo Marcelo Arenas Belón","SZEDER Gábor","Taylor Blau","Johannes Schindelin","rsbecker@nexbridge.com","Carlo Arenas"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"454329","messageId":"4ef9287b-6260-9538-7c89-cffb611520ee@maurel.de","threadId":"57785","inReplyTo":null,"subject":"a problem with git describe","fromName":"Guy Maurel","fromEmail":"guy.j@maurel.de","sentAt":"2022-04-23T09:12:16Z","receivedAt":"2022-04-23T09:18:35Z","isPatch":false,"sender":{"key":"guy.j@maurel.de","avatar":null},"body":"Hello!\n\nI am using git version 2.25.1\n\n6-8 weeks ago I don't get any problem.\nNow I get :\nguy@renard ~/Software/uncrustify $ sudo git describe --always --dirty\n[sudo] password for guy:\nfatal: unsafe repository ('/home/guy/Software/uncrustify' is owned by someone else)\n\nWhat is to do?\n\nThanks for any help\nguy\n-- \nGuy Maurel\nSebastian-Fischer-Weg 13\n89077 Ulm/ Germany\n"},{"id":"454332","messageId":"3d762060-b817-0246-c4a2-8eb35096cb7f@iee.email","threadId":"57785","inReplyTo":"4ef9287b-6260-9538-7c89-cffb611520ee@maurel.de","subject":"Re: a problem with git describe","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2022-04-23T11:27:40Z","receivedAt":"2022-04-23T11:27:49Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi Guy,\n\nOn 23/04/2022 10:12, Guy Maurel wrote:\n> Hello!\n>\n> I am using git version 2.25.1\n>\n> 6-8 weeks ago I don't get any problem.\n> Now I get :\n> guy@renard ~/Software/uncrustify $ sudo git describe --always --dirty\n> [sudo] password for guy:\n> fatal: unsafe repository ('/home/guy/Software/uncrustify' is owned by\n> someone else)\n>\n> What is to do?\n>\nThere was a security warning noted in recent maintenance releases, see\nhttps://lore.kernel.org/git/20220414003839.1616296-2-gitster@pobox.com/\nwhere users could be fooled to access unsafe repositories that they\ndidn't own.\n\nYou may have received a maintenance update that makes this check now the\ndefault.\n\nCould you check what `git version` reports? \n\nThere has also been added an escape hatch of allowing \"*\" for the\npermitted safe directories. but do check the updated manuals, and the\ngit mailing list archive (update the search in the above link).\n--\nPhilip\n"},{"id":"454341","messageId":"xmqqczh73hns.fsf@gitster.g","threadId":"57785","inReplyTo":"3d762060-b817-0246-c4a2-8eb35096cb7f@iee.email","subject":"Re: a problem with git describe","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-23T16:09:59Z","receivedAt":"2022-04-23T16:10:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philip Oakley <philipoakley@iee.email> writes:\n\n>> guy@renard ~/Software/uncrustify $ sudo git describe --always --dirty\n> ...\n> There has also been added an escape hatch of allowing \"*\" for the\n> permitted safe directories. but do check the updated manuals, and the\n> git mailing list archive (update the search in the above link).\n\nIn this particular case, I do not think '*' is needed, but you need\nto be careful here.  Whose configuration are you suggesting to add\nsuch an entry?  Yourself?  ~root/.gitconfig?\n\nI wonder if we should loosen \"the same owner\" check somewhat to\ncover this situation better.  I expect people also run the\ninstallation in repositories they own with \"sudo make install\",\nand complaining \"euid does not own that repository\" when it is\nmerely because they are running as root (and their real identity\nis still in ruid) feels a bit too strict to be useful.\n\nDscho, what do you think?\n\n"},{"id":"454348","messageId":"xmqqk0bf1i12.fsf@gitster.g","threadId":"57785","inReplyTo":"xmqqczh73hns.fsf@gitster.g","subject":"Re: a problem with git describe","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-23T23:44:57Z","receivedAt":"2022-04-23T23:45:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Philip Oakley <philipoakley@iee.email> writes:\n>\n>>> guy@renard ~/Software/uncrustify $ sudo git describe --always --dirty\n>> ...\n>> There has also been added an escape hatch of allowing \"*\" for the\n>> permitted safe directories. but do check the updated manuals, and the\n>> git mailing list archive (update the search in the above link).\n>\n> In this particular case, I do not think '*' is needed, but you need\n> to be careful here.  Whose configuration are you suggesting to add\n> such an entry?  Yourself?  ~root/.gitconfig?\n>\n> I wonder if we should loosen \"the same owner\" check somewhat to\n> cover this situation better.  I expect people also run the\n> installation in repositories they own with \"sudo make install\",\n> and complaining \"euid does not own that repository\" when it is\n> merely because they are running as root (and their real identity\n> is still in ruid) feels a bit too strict to be useful.\n\nActually, not quite.  when \"git\" runs in \"sudo git\", the real\nidentity has long lost, so the below would not help.  Sigh.\n\n git-compat-util.h | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git i/git-compat-util.h w/git-compat-util.h\nindex 63ba89dd31..90dc1b17cd 100644\n--- i/git-compat-util.h\n+++ w/git-compat-util.h\n@@ -398,7 +398,7 @@ static inline int is_path_owned_by_current_uid(const char *path)\n \tstruct stat st;\n \tif (lstat(path, &st))\n \t\treturn 0;\n-\treturn st.st_uid == geteuid();\n+\treturn st.st_uid == geteuid() || st.st_uid == getuid();\n }\n \n #define is_path_owned_by_current_user is_path_owned_by_current_uid\n"},{"id":"454362","messageId":"20220425020108.5agdq6bdg6umrtbt@carlos-mbp.lan","threadId":"57785","inReplyTo":"xmqqk0bf1i12.fsf@gitster.g","subject":"Re: a problem with git describe","fromName":"Carlo Marcelo Arenas Belón","fromEmail":"carenas@gmail.com","sentAt":"2022-04-25T02:01:08Z","receivedAt":"2022-04-25T02:01:16Z","isPatch":false,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Sat, Apr 23, 2022 at 04:44:57PM -0700, Junio C Hamano wrote:\n> \n> Actually, not quite.  when \"git\" runs in \"sudo git\", the real\n> identity has long lost\n\nRight, but in this specific case, the terminal is still a good indication\nof who the user is, so the following would work.\n\ndiff --git a/git-compat-util.h b/git-compat-util.h\nindex 58fd813bd01..5d5d91688ee 100644\n--- a/git-compat-util.h\n+++ b/git-compat-util.h\n@@ -442,6 +442,11 @@ static inline int is_path_owned_by_current_uid(const char *path)\n \tstruct stat st;\n \tif (lstat(path, &st))\n \t\treturn 0;\n+\tif (isatty(1)) {\n+\t\tstruct stat ttyst;\n+\t\tif (!stat(ttyname(1), &ttyst))\n+\t\t\treturn st.st_uid == ttyst.st_uid;\n+\t}\n \treturn st.st_uid == geteuid();\n }\n \nIt obviously needs more polishing and portability work, though, and I don't\nlike that it makes the general case more complicated, so maybe would be better\nto only do it running as root?\n\nAt that point, though you might as well excempt root from this check\n\nCarlo\n"},{"id":"454363","messageId":"20220425050549.GA3280@szeder.dev","threadId":"57785","inReplyTo":"20220425020108.5agdq6bdg6umrtbt@carlos-mbp.lan","subject":"Re: a problem with git describe","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2022-04-25T05:05:49Z","receivedAt":"2022-04-25T05:06:04Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Sun, Apr 24, 2022 at 07:01:08PM -0700, Carlo Marcelo Arenas Belón wrote:\n> On Sat, Apr 23, 2022 at 04:44:57PM -0700, Junio C Hamano wrote:\n> > \n> > Actually, not quite.  when \"git\" runs in \"sudo git\", the real\n> > identity has long lost\n> \n> Right, but in this specific case, the terminal is still a good indication\n> of who the user is, so the following would work.\n> \n> diff --git a/git-compat-util.h b/git-compat-util.h\n> index 58fd813bd01..5d5d91688ee 100644\n> --- a/git-compat-util.h\n> +++ b/git-compat-util.h\n> @@ -442,6 +442,11 @@ static inline int is_path_owned_by_current_uid(const char *path)\n>  \tstruct stat st;\n>  \tif (lstat(path, &st))\n>  \t\treturn 0;\n> +\tif (isatty(1)) {\n> +\t\tstruct stat ttyst;\n> +\t\tif (!stat(ttyname(1), &ttyst))\n> +\t\t\treturn st.st_uid == ttyst.st_uid;\n> +\t}\n>  \treturn st.st_uid == geteuid();\n>  }\n\nOur 'GIT-VERSION-GEN' runs 'var=$(git describe ...)', so standard\noutput is not a terminal during 'sudo make install'\n\n> It obviously needs more polishing and portability work, though, and I don't\n> like that it makes the general case more complicated, so maybe would be better\n> to only do it running as root?\n> \n> At that point, though you might as well excempt root from this check\n> \n> Carlo\n"},{"id":"454364","messageId":"20220425060310.57tzqjopniul7h5p@carlos-mbp.lan","threadId":"57785","inReplyTo":"20220425050549.GA3280@szeder.dev","subject":"Re: a problem with git describe","fromName":"Carlo Marcelo Arenas Belón","fromEmail":"carenas@gmail.com","sentAt":"2022-04-25T06:03:10Z","receivedAt":"2022-04-25T06:04:24Z","isPatch":false,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Mon, Apr 25, 2022 at 07:05:49AM +0200, SZEDER Gábor wrote:\n> On Sun, Apr 24, 2022 at 07:01:08PM -0700, Carlo Marcelo Arenas Belón wrote:\n> > On Sat, Apr 23, 2022 at 04:44:57PM -0700, Junio C Hamano wrote:\n> > > \n> > > Actually, not quite.  when \"git\" runs in \"sudo git\", the real\n> > > identity has long lost\n> > \n> > Right, but in this specific case, the terminal is still a good indication\n> > of who the user is, so the following would work.\n> > \n> > diff --git a/git-compat-util.h b/git-compat-util.h\n> > index 58fd813bd01..5d5d91688ee 100644\n> > --- a/git-compat-util.h\n> > +++ b/git-compat-util.h\n> > @@ -442,6 +442,11 @@ static inline int is_path_owned_by_current_uid(const char *path)\n> >  \tstruct stat st;\n> >  \tif (lstat(path, &st))\n> >  \t\treturn 0;\n> > +\tif (isatty(1)) {\n> > +\t\tstruct stat ttyst;\n> > +\t\tif (!stat(ttyname(1), &ttyst))\n> > +\t\t\treturn st.st_uid == ttyst.st_uid;\n> > +\t}\n> >  \treturn st.st_uid == geteuid();\n> >  }\n> \n> Our 'GIT-VERSION-GEN' runs 'var=$(git describe ...)', so standard\n> output is not a terminal during 'sudo make install'\n\ndidn't realize the orginal report was coming from `sudo make install`\nin git's own repository, but even that worked for me.\n\nwhen I meant the original case I went with an artificial test where\nI run :\n\n  $ mkdir -p r/t\n  $ sudo chown root r\n  $ cd r/t\n  $ git init\n  $ sudo git status\n\nand I get no error, unlike the original version of the code.\n\nof course, part of the \"extra work needed\" is to figure out if stdout\nis the best place to look at, I chose it just because that is the\nunoficial way to signal in our code that we are running interactively.\n\nnote that usually unless a pipe is involved or nohup is used, the tty\nis still attached to your process.\n\nCarlo\n"},{"id":"454366","messageId":"xmqqy1zty8dc.fsf@gitster.g","threadId":"57785","inReplyTo":"20220425020108.5agdq6bdg6umrtbt@carlos-mbp.lan","subject":"Re: a problem with git describe","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-25T06:39:27Z","receivedAt":"2022-04-25T06:39:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlo Marcelo Arenas Belón <carenas@gmail.com> writes:\n\n> At that point, though you might as well excempt root from this check\n\nBut \"root\" or any higher-valued account is what needs this kind of\nprotection the most, no?  The protection is *not* about people\nknowingly accessing their own repository via \"root\", but those who\nare in a directory without being aware of its repository-ness.  You\nprepare /var/tmp/.git/ and let others do things that they would do\nin /var/tmp/ throw-away directories normally and get affected by\nwhat you leave in /var/tmp/.git/config file.  If \"root\" is among\nthese \"others\", that sounds like you caught a bigger fish X-<.\n"},{"id":"454367","messageId":"20220425070245.ta6wibzkezlfwzxp@carlos-mbp.lan","threadId":"57785","inReplyTo":"xmqqy1zty8dc.fsf@gitster.g","subject":"Re: a problem with git describe","fromName":"Carlo Marcelo Arenas Belón","fromEmail":"carenas@gmail.com","sentAt":"2022-04-25T07:02:45Z","receivedAt":"2022-04-25T07:03:02Z","isPatch":false,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Sun, Apr 24, 2022 at 11:39:27PM -0700, Junio C Hamano wrote:\n> Carlo Marcelo Arenas Belón <carenas@gmail.com> writes:\n> \n> > At that point, though you might as well excempt root from this check\n> \n> But \"root\" or any higher-valued account is what needs this kind of\n> protection the most, no?\n\ncorrect, and I didn't meant to excempt root from the protection, but\nfrom the check that requires that the config file ownership matches.\n\nif the config file is owned by root, we already lost, regardless of what\nuid git is running as.\n\nFWIW the proposed change doesn't weaken the current protection, it just\nallows a git process that is running as root (through sudo) to figure\nout what real user was the terminal session running as, so it wouldn't\nincorrectly triggeer an error.\n\n> The protection is *not* about people\n> knowingly accessing their own repository via \"root\",\n\nnope, but the regression that was described by the original post is\n\nCarlo\n"},{"id":"454372","messageId":"20220425084003.nf267feurpqyvmsd@carlos-mbp.lan","threadId":"57785","inReplyTo":"20220425070245.ta6wibzkezlfwzxp@carlos-mbp.lan","subject":"Re: a problem with git describe","fromName":"Carlo Marcelo Arenas Belón","fromEmail":"carenas@gmail.com","sentAt":"2022-04-25T08:40:03Z","receivedAt":"2022-04-25T08:40:18Z","isPatch":false,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Mon, Apr 25, 2022 at 12:02:45AM -0700, Carlo Marcelo Arenas Belón wrote:\n> On Sun, Apr 24, 2022 at 11:39:27PM -0700, Junio C Hamano wrote:\n> > Carlo Marcelo Arenas Belón <carenas@gmail.com> writes:\n> > \n> > > At that point, though you might as well excempt root from this check\n> > \n> > But \"root\" or any higher-valued account is what needs this kind of\n> > protection the most, no?\n> \n> correct, and I didn't meant to excempt root from the protection, but\n> from the check that requires that the config file ownership matches.\n> \n> if the config file is owned by root, we already lost, regardless of what\n> uid git is running as.\n\napologies for my confusing english, hopefully this C is clearer\n\ndiff --git a/git-compat-util.h b/git-compat-util.h\nindex 58fd813bd01..6a385be7d1d 100644\n--- a/git-compat-util.h\n+++ b/git-compat-util.h\n@@ -440,9 +440,19 @@ static inline int git_offset_1st_component(const char *path)\n static inline int is_path_owned_by_current_uid(const char *path)\n {\n \tstruct stat st;\n+\tuid_t euid;\n+\n \tif (lstat(path, &st))\n \t\treturn 0;\n-\treturn st.st_uid == geteuid();\n+\n+\teuid = geteuid();\n+\tif (!euid && st.st_uid && isatty(0)) {\n+\t\tstruct stat ttyst;\n+\t\tif (!stat(ttyname(0), &ttyst))\n+\t\t\teuid = ttyst.st_uid;\n+\t}\n+\n+\treturn st.st_uid == euid;\n }\n \n #define is_path_owned_by_current_user is_path_owned_by_current_uid\n\nit uses stdin instead not to fall in the issue that was raised by\nGábor, but I am affraid that it might need to check all stdnandles for\na valid tty to be safe, and it looking even more complex.\n\nCarlo\n"},{"id":"454387","messageId":"02adbd7f-d806-1400-1f9c-a37a64b63981@maurel.de","threadId":"57785","inReplyTo":"20220425084003.nf267feurpqyvmsd@carlos-mbp.lan","subject":"Re: a problem with git describe","fromName":"Guy Maurel","fromEmail":"guy.j@maurel.de","sentAt":"2022-04-25T15:11:32Z","receivedAt":"2022-04-25T15:11:40Z","isPatch":false,"sender":{"key":"guy.j@maurel.de","avatar":null},"body":"Hello!\n\nIt might be important for your debugging work.\nI introduce a new file /root/.gitconfig\n-rw-r--r--  1 root root   57 Apr 25 17:03 .gitconfig\nwith\n[safe]\n         directory = /home/guy/Software/uncrustify\n\nAnd the call works pretty well:\nuncrustify/build $ sudo ~/Software/Git/2.36.0/tar-gz/git-2.36.0/git-describe\nuncrustify-0.74.0-315-ga3466c92\n\nThanks for helping!\nguy\nAm 25.04.22 um 10:40 schrieb Carlo Marcelo Arenas Belón:\n> On Mon, Apr 25, 2022 at 12:02:45AM -0700, Carlo Marcelo Arenas Belón wrote:\n>> On Sun, Apr 24, 2022 at 11:39:27PM -0700, Junio C Hamano wrote:\n>>> Carlo Marcelo Arenas Belón <carenas@gmail.com> writes:\n>>>\n>>>> At that point, though you might as well excempt root from this check\n>>>\n>>> But \"root\" or any higher-valued account is what needs this kind of\n>>> protection the most, no?\n>>\n>> correct, and I didn't meant to excempt root from the protection, but\n>> from the check that requires that the config file ownership matches.\n>>\n>> if the config file is owned by root, we already lost, regardless of what\n>> uid git is running as.\n> \n> apologies for my confusing english, hopefully this C is clearer\n> \n> diff --git a/git-compat-util.h b/git-compat-util.h\n> index 58fd813bd01..6a385be7d1d 100644\n> --- a/git-compat-util.h\n> +++ b/git-compat-util.h\n> @@ -440,9 +440,19 @@ static inline int git_offset_1st_component(const char *path)\n>   static inline int is_path_owned_by_current_uid(const char *path)\n>   {\n>   \tstruct stat st;\n> +\tuid_t euid;\n> +\n>   \tif (lstat(path, &st))\n>   \t\treturn 0;\n> -\treturn st.st_uid == geteuid();\n> +\n> +\teuid = geteuid();\n> +\tif (!euid && st.st_uid && isatty(0)) {\n> +\t\tstruct stat ttyst;\n> +\t\tif (!stat(ttyname(0), &ttyst))\n> +\t\t\teuid = ttyst.st_uid;\n> +\t}\n> +\n> +\treturn st.st_uid == euid;\n>   }\n>   \n>   #define is_path_owned_by_current_user is_path_owned_by_current_uid\n> \n> it uses stdin instead not to fall in the issue that was raised by\n> Gábor, but I am affraid that it might need to check all stdnandles for\n> a valid tty to be safe, and it looking even more complex.\n> \n> Carlo\n\n-- \nGuy Maurel\nSebastian-Fischer-Weg 13\n89077 Ulm\n"},{"id":"454419","messageId":"YmdQcrl/uu7HFBlc@nand.local","threadId":"57785","inReplyTo":"xmqqczh73hns.fsf@gitster.g","subject":"Re: a problem with git describe","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2022-04-26T01:52:50Z","receivedAt":"2022-04-26T01:52:58Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Sat, Apr 23, 2022 at 09:09:59AM -0700, Junio C Hamano wrote:\n> Philip Oakley <philipoakley@iee.email> writes:\n>\n> >> guy@renard ~/Software/uncrustify $ sudo git describe --always --dirty\n> > ...\n> > There has also been added an escape hatch of allowing \"*\" for the\n> > permitted safe directories. but do check the updated manuals, and the\n> > git mailing list archive (update the search in the above link).\n>\n> In this particular case, I do not think '*' is needed, but you need\n> to be careful here.  Whose configuration are you suggesting to add\n> such an entry?  Yourself?  ~root/.gitconfig?\n>\n> I wonder if we should loosen \"the same owner\" check somewhat to\n> cover this situation better.  I expect people also run the\n> installation in repositories they own with \"sudo make install\",\n> and complaining \"euid does not own that repository\" when it is\n> merely because they are running as root (and their real identity\n> is still in ruid) feels a bit too strict to be useful.\n\nI was thinking about this today and realized that my original train of\nthought along the lines of \"ignore the new safety check when the current\nuser has higher permissions than the user who owns the repository we're\nworking in\" was misguided.\n\nWhat about loosening the check in a different way? Instead of causing\nGit to abort early, what if we:\n\n  - skipped reading the repository's configuration and hooks (unless\n    safe.directory includes $CWD)\n  - emit a warning (which goes away when safe.directory contains $CWD)\n  - otherwise continue executing as normal\n\nThat would unbreak the case of $(git describe ...) in our Makefile in\nthis instance, without opening ourselves up to execution-via-config.\n\nThough I think we'd have to be slightly more careful than that, since\nwe definitely _do_ want to read repository format extensions.\n\nI'm hesitant to recommend reading some parts of the configuration\nwithout others, though this is slightly different than that. Instead of\nsaying \"read every entry of config except core.editor, core.pager,\ncore.alternateRefsCommand, core.fsmonitor\" and so on, this says \"when\noperating in a repository not owned by the current user (or the\nrepository is in our global safe.directory list) only read repository\nformat extensions, but ignore everything else in config and hooks\".\n\n> Dscho, what do you think?\n\nI'd be curious to hear what Johannes thinks of your original mail as\nwell as my own.\n\nThanks,\nTaylor\n"},{"id":"454438","messageId":"nycvar.QRO.7.76.6.2204261726460.355@tvgsbejvaqbjf.bet","threadId":"57785","inReplyTo":"xmqqczh73hns.fsf@gitster.g","subject":"Re: a problem with git describe","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-04-26T15:30:12Z","receivedAt":"2022-04-26T15:30:33Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Sat, 23 Apr 2022, Junio C Hamano wrote:\n\n> Philip Oakley <philipoakley@iee.email> writes:\n>\n> >> guy@renard ~/Software/uncrustify $ sudo git describe --always --dirty\n> > ...\n> > There has also been added an escape hatch of allowing \"*\" for the\n> > permitted safe directories. but do check the updated manuals, and the\n> > git mailing list archive (update the search in the above link).\n>\n> In this particular case, I do not think '*' is needed, but you need\n> to be careful here.  Whose configuration are you suggesting to add\n> such an entry?  Yourself?  ~root/.gitconfig?\n\nOne relatively simple work-around might be to call `sudo chown root .`\nbefore running `sudo make install`, but of course this would require the\n`rm -rf` to be run via `sudo`, too.\n\n> I wonder if we should loosen \"the same owner\" check somewhat to\n> cover this situation better.  I expect people also run the\n> installation in repositories they own with \"sudo make install\",\n> and complaining \"euid does not own that repository\" when it is\n> merely because they are running as root (and their real identity\n> is still in ruid) feels a bit too strict to be useful.\n\nIt's too bad that your fix to include euid seems not to work. That would\nhave been my preference.\n\nDo we want to make use of the environment variable `SUDO_UID` that is set\nby `sudo`?\n\nCiao,\nDscho\n"},{"id":"454439","messageId":"xmqqk0bbsvok.fsf@gitster.g","threadId":"57785","inReplyTo":"nycvar.QRO.7.76.6.2204261726460.355@tvgsbejvaqbjf.bet","subject":"Re: a problem with git describe","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-26T15:36:59Z","receivedAt":"2022-04-26T15:37:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> On Sat, 23 Apr 2022, Junio C Hamano wrote:\n>\n>> Philip Oakley <philipoakley@iee.email> writes:\n>>\n>> >> guy@renard ~/Software/uncrustify $ sudo git describe --always --dirty\n>> > ...\n>> > There has also been added an escape hatch of allowing \"*\" for the\n>> > permitted safe directories. but do check the updated manuals, and the\n>> > git mailing list archive (update the search in the above link).\n>>\n>> In this particular case, I do not think '*' is needed, but you need\n>> to be careful here.  Whose configuration are you suggesting to add\n>> such an entry?  Yourself?  ~root/.gitconfig?\n>\n> One relatively simple work-around might be to call `sudo chown root .`\n> before running `sudo make install`, but of course this would require the\n> `rm -rf` to be run via `sudo`, too.\n\nchown root may make it owned by nobody4, though ;-)\n\n> Do we want to make use of the environment variable `SUDO_UID` that is set\n> by `sudo`?\n\n\"run this command under 'sudo'\" would be a social engineering attack\nwe do not want to defend against, so I am OK with that, but then\nallowing\n\n    sudo \"GIT_SAFE_DIRECTORIES=. make install\"\n\ndoes not look too bad, either.\n\n\n\n"},{"id":"454440","messageId":"nycvar.QRO.7.76.6.2204261730210.355@tvgsbejvaqbjf.bet","threadId":"57785","inReplyTo":"YmdQcrl/uu7HFBlc@nand.local","subject":"Re: a problem with git describe","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-04-26T15:41:36Z","receivedAt":"2022-04-26T15:41:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Taylor,\n\nOn Mon, 25 Apr 2022, Taylor Blau wrote:\n\n> On Sat, Apr 23, 2022 at 09:09:59AM -0700, Junio C Hamano wrote:\n> > Philip Oakley <philipoakley@iee.email> writes:\n> >\n> > >> guy@renard ~/Software/uncrustify $ sudo git describe --always --dirty\n> > > ...\n> > > There has also been added an escape hatch of allowing \"*\" for the\n> > > permitted safe directories. but do check the updated manuals, and the\n> > > git mailing list archive (update the search in the above link).\n> >\n> > In this particular case, I do not think '*' is needed, but you need\n> > to be careful here.  Whose configuration are you suggesting to add\n> > such an entry?  Yourself?  ~root/.gitconfig?\n> >\n> > I wonder if we should loosen \"the same owner\" check somewhat to\n> > cover this situation better.  I expect people also run the\n> > installation in repositories they own with \"sudo make install\",\n> > and complaining \"euid does not own that repository\" when it is\n> > merely because they are running as root (and their real identity\n> > is still in ruid) feels a bit too strict to be useful.\n>\n> I was thinking about this today and realized that my original train of\n> thought along the lines of \"ignore the new safety check when the current\n> user has higher permissions than the user who owns the repository we're\n> working in\" was misguided.\n>\n> What about loosening the check in a different way? Instead of causing\n> Git to abort early, what if we:\n>\n>   - skipped reading the repository's configuration and hooks (unless\n>     safe.directory includes $CWD)\n>   - emit a warning (which goes away when safe.directory contains $CWD)\n>   - otherwise continue executing as normal\n>\n> That would unbreak the case of $(git describe ...) in our Makefile in\n> this instance, without opening ourselves up to execution-via-config.\n>\n> Though I think we'd have to be slightly more careful than that, since\n> we definitely _do_ want to read repository format extensions.\n>\n> I'm hesitant to recommend reading some parts of the configuration\n> without others, though this is slightly different than that. Instead of\n> saying \"read every entry of config except core.editor, core.pager,\n> core.alternateRefsCommand, core.fsmonitor\" and so on, this says \"when\n> operating in a repository not owned by the current user (or the\n> repository is in our global safe.directory list) only read repository\n> format extensions, but ignore everything else in config and hooks\".\n\nThis idea to disable \"just the unsafe parts\" has come up before, and I do\nnot really like it. It would change Git's behavior in inconsistent,\nhard-to-explain ways. For example, we would have to disable clean/smudge\nfilters, which would then break, say, Git LFS.\n\nSure, for something like `core.fsmonitor` which is a pure performance\nknob, where Git works correctly whether you heed that setting or not (just\nwith different performance characteristics), it might be fine. But for\nthings like the clean/smudge filters, it changes behavior. And the worst\npart? If we introduce something like this logic (\"if the worktree is owned\nby somebody else, just ignore the parts of the config that refer to\nuser-defined programs to be executed\"), we give wrong results _without\nhaving a way to tell the user that we do that_. Unless you want to see a\nwarning \"you may see incorrect results\" every time you run `sudo git\nstatus`?\n\nDon't get me wrong, we _will_ want to have a serious discussion about the\nconfig and how we let features creep in that can be exploited if an\nadversary gains write access to one of the various places from where Git\nreads config, and how we can mitigate that. IIRC we used to treat the\nconfig as something safe \"because it does not execute code\", this came up\ne.g. when we introduced `.gitmodules`.\n\nI just don't think that we can use \"is this thing owned by us?\" as a knob\nthat asks Git to ignore all config settings referring to paths of\nexecutables it is supposed to run at one stage or another.\n\nCiao,\nDscho\n"},{"id":"454441","messageId":"nycvar.QRO.7.76.6.2204261742120.355@tvgsbejvaqbjf.bet","threadId":"57785","inReplyTo":"20220425084003.nf267feurpqyvmsd@carlos-mbp.lan","subject":"Re: a problem with git describe","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-04-26T15:43:32Z","receivedAt":"2022-04-26T15:43:52Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Carlo,\n\nOn Mon, 25 Apr 2022, Carlo Marcelo Arenas Belón wrote:\n\n> On Mon, Apr 25, 2022 at 12:02:45AM -0700, Carlo Marcelo Arenas Belón wrote:\n> > On Sun, Apr 24, 2022 at 11:39:27PM -0700, Junio C Hamano wrote:\n> > > Carlo Marcelo Arenas Belón <carenas@gmail.com> writes:\n> > >\n> > > > At that point, though you might as well excempt root from this check\n> > >\n> > > But \"root\" or any higher-valued account is what needs this kind of\n> > > protection the most, no?\n> >\n> > correct, and I didn't meant to excempt root from the protection, but\n> > from the check that requires that the config file ownership matches.\n> >\n> > if the config file is owned by root, we already lost, regardless of what\n> > uid git is running as.\n>\n> apologies for my confusing english, hopefully this C is clearer\n>\n> diff --git a/git-compat-util.h b/git-compat-util.h\n> index 58fd813bd01..6a385be7d1d 100644\n> --- a/git-compat-util.h\n> +++ b/git-compat-util.h\n> @@ -440,9 +440,19 @@ static inline int git_offset_1st_component(const char *path)\n>  static inline int is_path_owned_by_current_uid(const char *path)\n>  {\n>  \tstruct stat st;\n> +\tuid_t euid;\n> +\n>  \tif (lstat(path, &st))\n>  \t\treturn 0;\n> -\treturn st.st_uid == geteuid();\n> +\n> +\teuid = geteuid();\n> +\tif (!euid && st.st_uid && isatty(0)) {\n> +\t\tstruct stat ttyst;\n> +\t\tif (!stat(ttyname(0), &ttyst))\n> +\t\t\teuid = ttyst.st_uid;\n> +\t}\n> +\n> +\treturn st.st_uid == euid;\n>  }\n>\n>  #define is_path_owned_by_current_user is_path_owned_by_current_uid\n>\n> it uses stdin instead not to fall in the issue that was raised by\n> Gábor, but I am affraid that it might need to check all stdnandles for\n> a valid tty to be safe, and it looking even more complex.\n\nMaybe a better idea for the `sudo` scenario would be to make use of\n`SUDO_UID` (assuming that no adversary can gain control over the user's\nenvironment variables)?\n\nCiao,\nDscho\n"},{"id":"454442","messageId":"nycvar.QRO.7.76.6.2204261743590.355@tvgsbejvaqbjf.bet","threadId":"57785","inReplyTo":"xmqqk0bf1i12.fsf@gitster.g","subject":"Re: a problem with git describe","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-04-26T15:45:37Z","receivedAt":"2022-04-26T15:45:58Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Sat, 23 Apr 2022, Junio C Hamano wrote:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n> > Philip Oakley <philipoakley@iee.email> writes:\n> >\n> >>> guy@renard ~/Software/uncrustify $ sudo git describe --always --dirty\n> >> ...\n> >> There has also been added an escape hatch of allowing \"*\" for the\n> >> permitted safe directories. but do check the updated manuals, and the\n> >> git mailing list archive (update the search in the above link).\n> >\n> > In this particular case, I do not think '*' is needed, but you need\n> > to be careful here.  Whose configuration are you suggesting to add\n> > such an entry?  Yourself?  ~root/.gitconfig?\n> >\n> > I wonder if we should loosen \"the same owner\" check somewhat to\n> > cover this situation better.  I expect people also run the\n> > installation in repositories they own with \"sudo make install\",\n> > and complaining \"euid does not own that repository\" when it is\n> > merely because they are running as root (and their real identity\n> > is still in ruid) feels a bit too strict to be useful.\n>\n> Actually, not quite.  when \"git\" runs in \"sudo git\", the real\n> identity has long lost, so the below would not help.  Sigh.\n\nCould you help me understand what is going on exactly? How/when is `git`\nrunning `sudo git`? I thought the problem was that `sudo make install`\ntransitively runs `git describe` with euid 0, but `getuid()` should still\nreturn the non-admin user's ID, no?\n\nThanks,\nDscho\n\n>\n>  git-compat-util.h | 2 +-\n>  1 file changed, 1 insertion(+), 1 deletion(-)\n>\n> diff --git i/git-compat-util.h w/git-compat-util.h\n> index 63ba89dd31..90dc1b17cd 100644\n> --- i/git-compat-util.h\n> +++ w/git-compat-util.h\n> @@ -398,7 +398,7 @@ static inline int is_path_owned_by_current_uid(const char *path)\n>  \tstruct stat st;\n>  \tif (lstat(path, &st))\n>  \t\treturn 0;\n> -\treturn st.st_uid == geteuid();\n> +\treturn st.st_uid == geteuid() || st.st_uid == getuid();\n>  }\n>\n>  #define is_path_owned_by_current_user is_path_owned_by_current_uid\n>\n"},{"id":"454443","messageId":"YmgUqbawbHGRTNBD@nand.local","threadId":"57785","inReplyTo":"nycvar.QRO.7.76.6.2204261730210.355@tvgsbejvaqbjf.bet","subject":"Re: a problem with git describe","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2022-04-26T15:50:01Z","receivedAt":"2022-04-26T15:50:14Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Tue, Apr 26, 2022 at 05:41:36PM +0200, Johannes Schindelin wrote:\n> This idea to disable \"just the unsafe parts\" has come up before, and I do\n> not really like it. It would change Git's behavior in inconsistent,\n> hard-to-explain ways. For example, we would have to disable clean/smudge\n> filters, which would then break, say, Git LFS.\n\nI share your sentiment on the \"don't read the unsafe parts\" bit.\n\nI think replacing our behavior from 2.35.2 from \"bail on every execution\nof Git in an unowned directory not listed in safe.directory\" to \"emit a\nwarning and don't read config/hooks in an unowned [...]\" is a little\nfriendlier in the sense that it would avoid breaking too many workflows\nwithout opening us up to the attack described and mitigate by that\nrelease.\n\nA warning is definitely appropriate to tell users when we are and aren't\nreading config. I strongly dislike \"read some parts of config and not\nothers\" though, since it seems (a) even harder to explain and\ninconsistent than this, and (b) extremely error prone and fragile in the\nsense that we are unlikely to completely enumerate every possible config\n-> execution path in git-config(1).\n\nThanks,\nTaylor\n"},{"id":"454446","messageId":"049e01d85986$2afeeff0$80fccfd0$@nexbridge.com","threadId":"57785","inReplyTo":"nycvar.QRO.7.76.6.2204261742120.355@tvgsbejvaqbjf.bet","subject":"RE: a problem with git describe","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2022-04-26T15:56:13Z","receivedAt":"2022-04-26T15:56:35Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On April 26, 2022 11:44 AM, Johannes Schindelin wrote:\n>On Mon, 25 Apr 2022, Carlo Marcelo Arenas Belón wrote:\n>\n>> On Mon, Apr 25, 2022 at 12:02:45AM -0700, Carlo Marcelo Arenas Belón wrote:\n>> > On Sun, Apr 24, 2022 at 11:39:27PM -0700, Junio C Hamano wrote:\n>> > > Carlo Marcelo Arenas Belón <carenas@gmail.com> writes:\n>> > >\n>> > > > At that point, though you might as well excempt root from this\n>> > > > check\n>> > >\n>> > > But \"root\" or any higher-valued account is what needs this kind of\n>> > > protection the most, no?\n>> >\n>> > correct, and I didn't meant to excempt root from the protection, but\n>> > from the check that requires that the config file ownership matches.\n>> >\n>> > if the config file is owned by root, we already lost, regardless of\n>> > what uid git is running as.\n>>\n>> apologies for my confusing english, hopefully this C is clearer\n>>\n>> diff --git a/git-compat-util.h b/git-compat-util.h index\n>> 58fd813bd01..6a385be7d1d 100644\n>> --- a/git-compat-util.h\n>> +++ b/git-compat-util.h\n>> @@ -440,9 +440,19 @@ static inline int git_offset_1st_component(const\n>> char *path)  static inline int is_path_owned_by_current_uid(const char\n>> *path)  {\n>>  \tstruct stat st;\n>> +\tuid_t euid;\n>> +\n>>  \tif (lstat(path, &st))\n>>  \t\treturn 0;\n>> -\treturn st.st_uid == geteuid();\n>> +\n>> +\teuid = geteuid();\n>> +\tif (!euid && st.st_uid && isatty(0)) {\n>> +\t\tstruct stat ttyst;\n>> +\t\tif (!stat(ttyname(0), &ttyst))\n>> +\t\t\teuid = ttyst.st_uid;\n>> +\t}\n>> +\n>> +\treturn st.st_uid == euid;\n>>  }\n>>\n>>  #define is_path_owned_by_current_user is_path_owned_by_current_uid\n>>\n>> it uses stdin instead not to fall in the issue that was raised by\n>> Gábor, but I am affraid that it might need to check all stdnandles for\n>> a valid tty to be safe, and it looking even more complex.\n>\n>Maybe a better idea for the `sudo` scenario would be to make use of `SUDO_UID`\n>(assuming that no adversary can gain control over the user's environment\n>variables)?\n\nPlease do not assume that the user id 0 represents root. It does not on all systems. This change will cause breakages. We would need a specific comparison in compat.c with platform-specific values.\nFor example:\n\n#if defined __TANDEM\n#define ROOT_UID 65535\n#define ROOT_GID 255\n#endif\n\n--Randall\n\n"},{"id":"454451","messageId":"xmqqtuafrevv.fsf@gitster.g","threadId":"57785","inReplyTo":"nycvar.QRO.7.76.6.2204261743590.355@tvgsbejvaqbjf.bet","subject":"Re: a problem with git describe","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-26T16:25:08Z","receivedAt":"2022-04-26T16:25:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n>> Actually, not quite.  when \"git\" runs in \"sudo git\", the real\n>> identity has long lost, so the below would not help.  Sigh.\n>\n> Could you help me understand what is going on exactly? How/when is `git`\n> running `sudo git`? I thought the problem was that `sudo make install`\n> transitively runs `git describe` with euid 0, but `getuid()` should still\n> return the non-admin user's ID, no?\n\nThe first \"git\" is literal English meaning, refers to a person ;-)\n\nAnybody building and installing git would do\n\n\t$ sudo make\n\t$ sudo make install\n\nand no, sudo does not leave a clue in getuid() from whom it came from.\n\n"},{"id":"454452","messageId":"CAPUEspiufPMZOfZFunTFYmX7KwPxsKsAeHnfBjKgosA1ZJWqzw@mail.gmail.com","threadId":"57785","inReplyTo":"nycvar.QRO.7.76.6.2204261742120.355@tvgsbejvaqbjf.bet","subject":"Re: a problem with git describe","fromName":"Carlo Arenas","fromEmail":"carenas@gmail.com","sentAt":"2022-04-26T16:35:18Z","receivedAt":"2022-04-26T16:35:33Z","isPatch":false,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Tue, Apr 26, 2022 at 8:43 AM Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n>\n> Maybe a better idea for the `sudo` scenario would be to make use of\n> `SUDO_UID` (assuming that no adversary can gain control over the user's\n> environment variables)?\n\nI like this idea, and will prepare a formal patch soon also including DOAS_UID\nfor anyone that might have used that instead of sudo to elevate their\nprivileges.\n\nStill think that (since we are already touching this) removing the\nrestriction to\nroot owned directories might make sense though, ex the following (unrealistic\nexample) would work:\n\n  $ mkdir -p r/t\n  $ sudo chown root r\n  $ cd r && sudo git init\n  $ cd t && git status\n\nIMHO any directories above that are owned by root and might have a git\nconfiguration must be safe, and therefore shouldn't need to be\nexplicitly exempted.\n\nI also think that Taylor's suggestion to ignore and warn instead of\nabort might be\na better solution to the \"configuration file shouldn't be trusted\"\nissue which is at\nthe root of this regression, and obviously doing that would make this\nchange less\ncritical (users will just get a warning instead of being prevented to\ndo what worked\nfor them before and is a safe use case)\n\nCarlo\n\nPS. yes hardcoding uid 0 as root would be avoided, not sure where yet though\n"},{"id":"454453","messageId":"xmqqpml3rdwx.fsf@gitster.g","threadId":"57785","inReplyTo":"CAPUEspiufPMZOfZFunTFYmX7KwPxsKsAeHnfBjKgosA1ZJWqzw@mail.gmail.com","subject":"Re: a problem with git describe","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-26T16:46:06Z","receivedAt":"2022-04-26T16:48:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlo Arenas <carenas@gmail.com> writes:\n\n> Still think that (since we are already touching this) removing the\n> restriction to\n> root owned directories might make sense though, ex the following (unrealistic\n> example) would work:\n\nI think it is essential to protect unsuspecting \"root\" user from\nwandering into an unfamiliar directory that happens to be a trap,\ni.e. I may do something like this as an admin:\n\n    $ sudo sh\n    # cd / && find usr bin ... >/var/tmp/mylist.txt\n    # cd /var/tmp\n\nwith the expectation that I'd then do some text processing on the\nmylist.txt file, and going there first would allow me to refer to\nthe files more easily, instead of having to say:\n\n    # sed -e '... processing ...' </var/tmp/mylist.txt >/var/tmp/out.txt\n\nAlas, you as an attacker have done\n\n    $ cd /var/tmp\n    $ git init\n    $ edit .git/config\n\nto wait for me.  /var/tmp would be owned by 'root' but allows\nanybody to write to it, only forbidding people from removing other\npeople's stuff.\n\n\n\n>   $ mkdir -p r/t\n>   $ sudo chown root r\n>   $ cd r && sudo git init\n>   $ cd t && git status\n>\n> IMHO any directories above that are owned by root and might have a git\n> configuration must be safe, and therefore shouldn't need to be\n> explicitly exempted.\n>\n> I also think that Taylor's suggestion to ignore and warn instead of\n> abort might be\n> a better solution to the \"configuration file shouldn't be trusted\"\n> issue which is at\n> the root of this regression, and obviously doing that would make this\n> change less\n> critical (users will just get a warning instead of being prevented to\n> do what worked\n> for them before and is a safe use case)\n>\n> Carlo\n>\n> PS. yes hardcoding uid 0 as root would be avoided, not sure where yet though\n"},{"id":"454457","messageId":"CAPUEspi9mmoxehydOctGiCddUA0QtafXwKbMnprAWUPjO=vQDw@mail.gmail.com","threadId":"57785","inReplyTo":"xmqqpml3rdwx.fsf@gitster.g","subject":"Re: a problem with git describe","fromName":"Carlo Arenas","fromEmail":"carenas@gmail.com","sentAt":"2022-04-26T17:15:07Z","receivedAt":"2022-04-26T17:17:15Z","isPatch":false,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Tue, Apr 26, 2022 at 9:46 AM Junio C Hamano <gitster@pobox.com> wrote:\n>\n> Carlo Arenas <carenas@gmail.com> writes:\n>\n> > Still think that (since we are already touching this) removing the\n> > restriction to\n> > root owned directories might make sense though, ex the following (unrealistic\n> > example) would work:\n>\n> I think it is essential to protect unsuspecting \"root\" user from\n> wandering into an unfamiliar directory that happens to be a trap,\n> i.e. I may do something like this as an admin:\n>\n>     $ sudo sh\n>     # cd / && find usr bin ... >/var/tmp/mylist.txt\n>     # cd /var/tmp\n>\n> with the expectation that I'd then do some text processing on the\n> mylist.txt file, and going there first would allow me to refer to\n> the files more easily, instead of having to say:\n>\n>     # sed -e '... processing ...' </var/tmp/mylist.txt >/var/tmp/out.txt\n>\n> Alas, you as an attacker have done\n\nWhich is a career that has ended prematurely, it seems.\n\n>     $ cd /var/tmp\n>     $ git init\n>     $ edit .git/config\n>\n> to wait for me.  /var/tmp would be owned by 'root' but allows\n> anybody to write to it, only forbidding people from removing other\n> people's stuff.\n\nSince we are doing stat in that directory anyway, we should be able\nto notice the sticky bit and not fall from that trap, but I get why\n\"exempting root\" would be a bad idea.\n\nCarlo\n"}]}