| Message ID | 20220428105852.94449-3-carenas@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | fix `sudo make install` regression in maint | expand |
On Thu, Apr 28, 2022 at 03:58:51AM -0700, Carlo Marcelo Arenas Belón wrote: > In a previous patch, the behavior of git was changed so it will be able > to find the "effective uid" that is required when git was invoked with > sudo to root, for example the internal calls made to git when calling > the following in git's own repository: > > $ sudo make install > That is building Git, right?
Bagas Sanjaya <bagasdotme@gmail.com> writes: > On Thu, Apr 28, 2022 at 03:58:51AM -0700, Carlo Marcelo Arenas Belón wrote: >> In a previous patch, the behavior of git was changed so it will be able >> to find the "effective uid" that is required when git was invoked with >> sudo to root, for example the internal calls made to git when calling >> the following in git's own repository: >> >> $ sudo make install >> > > That is building Git, right? Why do you want to know? In other words, if Carlo answers "yes" (or "no" for that matter), what are you going to do with that piece of information? E-mailed communications with people on other continents are inherently high latency, so it is more efficient to try reducing number of round trips. One trick is to make sure that other side does not have to wonder "what do you need to know it for?" by telling them upfront why you want to know. Then they can guess better what kind of information to what detail you need, in order to move forward. If they agree where you want to go with the information is a good thing, it may even give them an incentive to give as high quality information as they can as quickly as they can to you. Having said all that. If you re-read the sentence before that sample command line, it would be clear that the answer is "yes, as that sentence said, it is building and installing Git". Especially "when calling the following in Git's own repository". But Git in that message is merely an example. Any piece of software that wants to run "git" as part of the "make install" procedure (e.g. to compute the version number, it may run "git describe", when it knows the build is being run in a Git managed repository, instead of being in a tarball extract) is affected.
On Sat, Apr 30, 2022 at 01:17:46PM +0700, Bagas Sanjaya wrote: > On Thu, Apr 28, 2022 at 03:58:51AM -0700, Carlo Marcelo Arenas Belón wrote: > > In a previous patch, the behavior of git was changed so it will be able > > to find the "effective uid" that is required when git was invoked with > > sudo to root, for example the internal calls made to git when calling > > the following in git's own repository: > > > > $ sudo make install > > > > That is building Git, right? Technically, installing it. The full report is more informative of what the specific impact is, which I obviously forgot to link to: https://lore.kernel.org/git/20220412180510.GA2173@szeder.dev/ Another example of it (which started this whole regression fix) is available in: https://lore.kernel.org/git/4ef9287b-6260-9538-7c89-cffb611520ee@maurel.de/ Carlo
diff --git a/Documentation/config/safe.txt b/Documentation/config/safe.txt index 6d764fe0ccf..ee558ced8c7 100644 --- a/Documentation/config/safe.txt +++ b/Documentation/config/safe.txt @@ -26,3 +26,12 @@ directory was listed in the `safe.directory` list. If `safe.directory=*` is set in system config and you want to re-enable this protection, then initialize your list with an empty value before listing the repositories that you deem safe. ++ +When git tries to check for ownership of git repositories, it will +obviously do so with the uid of the user that is running git itself, +but if git is running as root, it will check first if it might have +been started through `sudo`, and if that is the case, will instead +use the uid of the user that did so. +If that is not what you would prefer and want git to only trust +repositories that are owned by root instead, then you should remove +the `SUDO_UID` variable from root's environment.