| Message ID | 20220510174616.18629-3-carenas@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | fix `sudo make install` regression in maint | expand |
Carlo Marcelo Arenas Belón <carenas@gmail.com> writes: > This assumes the environment the user is running on after going > privileged can't be tampered with, and also adds code to restrict that > the new behavior only applies if running as root, therefore keeping the > most common case, which runs unprivileged, from changing, but because of > that, it will miss cases where sudo (or an equivalent) was used to change > to another unprivileged user or where the equivalent tool used to raise > privileges didn't track the original id in a sudo compatible way. Well written. > Because of compatibility with sudo, the code assumes that uid_t is an > unsigned integer type (which is not required by the standard) but is used > that way in their codebase to generate SUDO_UID. Heh, that is a good point. > ++ > +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, We do not need "obviously" here, but this has overlap with the beginning part of the safe.directory explanation, so I would probably suggest rewriting it altogether. > +but if git is running as root, in a platform that provides sudo and is > +not Windows, it will check first if it might have been started through Does Windows provide sudo that leaves the original user in SUDO_UID (I doubt it)? If not, then "on a platform that provides sudo, it will" would be sufficient. > +it, and if that is the case, will use the uid of the user that invoked > +sudo instead. As explained, Git only allows you to access repositories owned by yourself, i.e. the user who is running Git, by default. When Git is running as 'root', however, instead of allowing accesses to repositories owned by 'root', it checks the SUDO_UID environment variable and if it is set, allows access to repositories owned by the uid recorded as its value. This is to make it easy to perform a common sequence "make && sudo make install". A process running under 'sudo' runs as 'root' but the 'sudo' command exports the environment variable to record who the original user was. > +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. s/should/can/. But otherwise this is excellent. > diff --git a/git-compat-util.h b/git-compat-util.h > index 63ba89dd31..754cd90d43 100644 > --- a/git-compat-util.h > +++ b/git-compat-util.h > @@ -393,12 +393,64 @@ static inline int git_offset_1st_component(const char *path) > #endif > > #ifndef is_path_owned_by_current_user > + > +#ifdef __TANDEM > +#define ROOT_UID 65535 > +#else > +#define ROOT_UID 0 > +#endif > + > +/* > + * This helper function overrides a ROOT_UID with the one provided by > + * an environment variable, do not use unless the original user is > + * root or could be used as means to escalate to root privileges. I do not understand the "or could be used ..." at all. If the original user obtained from geteuid() is not root, then no matter what we do to *id here in this function, we won't let you gain the root privilege. The system won't let us give you the root privilege because we (Git) are running as a normal user. Or do you mean Do not use this function when (1) geteuid() did not say we are running as 'root', or (2) using this function will compromise the system. Then I can sort-of understand it, but (2) is a too obvious thing to say. > + * PORTABILITY WARNING: > + * This code assumes uid_t is unsigned because that is what sudo does. > + * If your uid_t type is signed and all your ids are positive then it > + * should all work fine, but need to make sure sudo never generates a > + * value higher than what can be represented by your uid_t type or a > + * negative value or it will trigger wraparound bugs. "sudo" generating a value higher than what uid_t can represent in SUDO_UID *is* a bug that we shouldn't have to worry about. Otherwise "sudo" as a tool would be unusable by folks with higher UID on their system. In their implementation of "sudo", they must have done getuid(), stored the value in uid_t and formatted it into a string. If they lost precision there by wrapping around or truncating, we can do nothing about it, but the thing is, we cannot even tell. > + * If that happens the uid used might be incorrect and then trigger > + * an access error from the filesystem itself. If uid we are extracting is incorrect, Git will fail to refuse access, the access is done as 'root', and filesystem level safety will not trigger. The end result is that I run "sudo git describe" in your repository and instead of getting refused, because our "sudo" was broken and SUDO_UID had your numeric uid, I execute "git" as root in your repository. IOW, this change is meant to make it slightly convenient to allow access to one's own stuff, but it got a bit more convenient by allowing me access to my own stuff plus yours ;-) > + * In the unlikely scenario this happened to you, and that is how you > + * got to this message, we would like to know about it by letting us > + * now with an email to git@vger.kernel.org indicating which platform, > + * you are running on and which version of sudo you used to see if we > + * can provide you a patch that would prevent this issue in the future. Nice. What message does the reporter see? > + */ > +static inline void extract_id_from_env(const char *env, uid_t *id) > +{ > + const char *real_uid = getenv(env); > + > + /* discard anything empty to avoid a more complex check below */ > + if (real_uid && *real_uid) { > + char *endptr = NULL; > + unsigned long env_id; > + > + errno = 0; > + /* silent overflow errors could trigger a bug below */ What "bug" are we referring to? > + env_id = strtoul(real_uid, &endptr, 10); > + if (!*endptr && !errno) > + *id = env_id; > + } > +} > + > static inline int is_path_owned_by_current_uid(const char *path) > { > struct stat st; > + uid_t euid; > + > if (lstat(path, &st)) > return 0; > - return st.st_uid == geteuid(); > + > + euid = geteuid(); > + if (euid == ROOT_UID) > + extract_id_from_env("SUDO_UID", &euid); > + > + return st.st_uid == euid; > } > > #define is_path_owned_by_current_user is_path_owned_by_current_uid > diff --git a/t/t0034-root-safe-directory.sh b/t/t0034-root-safe-directory.sh > index 2e4492a66d..ecd9dca6b3 100755 > --- a/t/t0034-root-safe-directory.sh > +++ b/t/t0034-root-safe-directory.sh > @@ -29,7 +29,7 @@ test_expect_success SUDO 'setup' ' > ) > ' > > -test_expect_failure SUDO 'sudo git status as original owner' ' > +test_expect_success SUDO 'sudo git status as original owner' ' > ( > cd root/r && > git status && OK. Thanks.
On Tue, May 10, 2022 at 3:57 PM Junio C Hamano <gitster@pobox.com> wrote: > > Because of compatibility with sudo, the code assumes that uid_t is an > > unsigned integer type (which is not required by the standard) but is used > > that way in their codebase to generate SUDO_UID. > > Heh, that is a good point. except it is an implementation detail we can't control, and that we have no way to test for (at least yet and definitely in these series) just because sudo upstream does this, doesn't mean the sudo that was built in that specific system does as well, and because strto*l will silently convert a value from one sign to another it might even "do the right thing" (tm) even when a signed uid_t exist and a negative one is valid. but since we are using a larger integer type to hold those values we are especially at risk of misbehaving when uid_t is signed because we didn't want to use atoi (and really couldn't safely). some systems provide UID_T_MAX as means to figure out (both if it is signed or not and to truncate safely), and I presume there are others where you can get that value at runtime with something like getconf(), but as you pointed out all that is moot if we still run as root so has been punted from this series and all that is left are these documented issues, which I meant to get to and fix ASAP (but with changes that will be more intrusive and wouldn't be safe for maint), but that I also want to leave clearly visible as bus factor protection. > > +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, > > We do not need "obviously" here, but this has overlap with the > beginning part of the safe.directory explanation, so I would > probably suggest rewriting it altogether. obviously > > +but if git is running as root, in a platform that provides sudo and is > > +not Windows, it will check first if it might have been started through > > Does Windows provide sudo that leaves the original user in SUDO_UID > (I doubt it)? If not, then "on a platform that provides sudo, it will" > would be sufficient. At least my windows box does not, but dscho's somehow had and so that line was added at his request[1] after he wasted so much time trying to get this to work and realized the function where SUDO_UID logic resides doesn't even exist in a Windows build. While I think it is probably ok to go, something that would save someone else that trouble is probably worth having one way or another, especially since he wasn't the only one while reviewing[2] this code, that got it wrong, either. > > +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. > > s/should/can/. But otherwise this is excellent. It weakens the message I wanted to apply to this as being a way to signal intention, and also being kind of the "official" way to do so for the future, but I agree it might be premature and it is obviously not that relevant once the next thing we might add is your code that fixes the "regression" and allows both root and SUDO_UID to work for this code. > > diff --git a/git-compat-util.h b/git-compat-util.h > > index 63ba89dd31..754cd90d43 100644 > > --- a/git-compat-util.h > > +++ b/git-compat-util.h > > @@ -393,12 +393,64 @@ static inline int git_offset_1st_component(const char *path) > > #endif > > > > #ifndef is_path_owned_by_current_user > > + > > +#ifdef __TANDEM > > +#define ROOT_UID 65535 > > +#else > > +#define ROOT_UID 0 > > +#endif > > + > > +/* > > + * This helper function overrides a ROOT_UID with the one provided by > > + * an environment variable, do not use unless the original user is > > + * root or could be used as means to escalate to root privileges. > > I do not understand the "or could be used ..." at all. If the > original user obtained from geteuid() is not root, then no matter > what we do to *id here in this function, we won't let you gain the > root privilege. The system won't let us give you the root privilege > because we (Git) are running as a normal user. It is just there to explain the risks of using this function (which is very visible) somewhere else, as well as to explain why it is only meant to be used in a process running as root. > Or do you mean > > Do not use this function when > > (1) geteuid() did not say we are running as 'root', or > (2) using this function will compromise the system. > > Then I can sort-of understand it, but (2) is a too obvious thing to > say. As usual I like your wording of it better, and yes I agree it is obvious but since this function is very visible (which is not necessary) and it is going to sit there in several maint releases, it might not be that all unwarranted IMHO. > > + * PORTABILITY WARNING: > > + * This code assumes uid_t is unsigned because that is what sudo does. > > + * If your uid_t type is signed and all your ids are positive then it > > + * should all work fine, but need to make sure sudo never generates a > > + * value higher than what can be represented by your uid_t type or a > > + * negative value or it will trigger wraparound bugs. > > "sudo" generating a value higher than what uid_t can represent in > SUDO_UID *is* a bug that we shouldn't have to worry about. > Otherwise "sudo" as a tool would be unusable by folks with higher > UID on their system. not necessarily; that system might had decided to use negative uids instead of changing to unsigned and everything will still work, but you are correct that in that case sudo printing the uid_t with "%u" is a bug in that sudo and should be fixed there, but the irony is that if fixed, would then cause a bug on our side since we assume uid was always positive and was printed with "%u". this whole message is there just to try to explain the portability issue that having signed uid_t might trigger and that would be unlikely to happen in real life as an alternative to try to do something about it (like I did in previous versions), or plainly refusing to run like you proposed (at least NONSTOP seems to have signed uid_t), specially considering this is in a maint track, I was thinking it might be something better done (in the future) and with all the portability bits hidden away in a proper compat file instead of here. > In their implementation of "sudo", they must have done getuid(), > stored the value in uid_t and formatted it into a string. If they > lost precision there by wrapping around or truncating, we can do > nothing about it, but the thing is, we cannot even tell. exactly, but we can warn the users that the problems they might have with this feature might be because of that, and the information they will provide could guide us into implementing a more portable version of this code in the future. and meanwhile, they might be able to keep a local patch which would be really simple to write on their side. > > + * If that happens the uid used might be incorrect and then trigger > > + * an access error from the filesystem itself. > > If uid we are extracting is incorrect, Git will fail to refuse > access, the access is done as 'root', and filesystem level safety > will not trigger. My bad, I didn't mean that the filesystem will trigger the error, but that we might fail to match the uid_t we got from the filesystem with the one we parsed from uid_t and therefore fail to allow access. Hopefully that mismatch would be easy to spot as well because of a compiler warning (like -Wsign-compare), or we might get lucky and might even work (ex: sizeof(long) == sizeof(uid_t)) > The end result is that I run "sudo git describe" > in your repository and instead of getting refused, because our "sudo" > was broken and SUDO_UID had your numeric uid, I execute "git" as root > in your repository. That shouldn't happen unless the overflow was big enough to trigger an ERANGE though, which also means uid_t would be much larger than the expected uint32_t it seems to have almost everywhere I looked. > IOW, this change is meant to make it slightly convenient to allow > access to one's own stuff, but it got a bit more convenient by > allowing me access to my own stuff plus yours ;-) Well, you said before that since we are running as root you can already have access to mine so it shouldn't matter ;) > > + * In the unlikely scenario this happened to you, and that is how you > > + * got to this message, we would like to know about it by letting us > > + * now with an email to git@vger.kernel.org indicating which platform, > > + * you are running on and which version of sudo you used to see if we > > + * can provide you a patch that would prevent this issue in the future. > > Nice. What message does the reporter see? when using `sudo git status` a rejection of access to the directory they own > > + */ > > +static inline void extract_id_from_env(const char *env, uid_t *id) > > +{ > > + const char *real_uid = getenv(env); > > + > > + /* discard anything empty to avoid a more complex check below */ > > + if (real_uid && *real_uid) { > > + char *endptr = NULL; > > + unsigned long env_id; > > + > > + errno = 0; > > + /* silent overflow errors could trigger a bug below */ > > What "bug" are we referring to? All of them, the ones we decided to ignore because they are irrelevant when running as root, and the ones that are documented in the long paragraph above. Carlo [1] https://lore.kernel.org/git/nycvar.QRO.7.76.6.2205051545370.355@tvgsbejvaqbjf.bet/ [2] https://lore.kernel.org/git/CAPUEspitAQrEjMpUyw8e2pyT1MT+h_dO5wSU0wWDWTqSye5TwA@mail.gmail.com/
Carlo Arenas <carenas@gmail.com> writes: >> Does Windows provide sudo that leaves the original user in SUDO_UID >> (I doubt it)? If not, then "on a platform that provides sudo, it will" >> would be sufficient. > > At least my windows box does not, but dscho's somehow had and so that > line was added at his request[1] after he wasted so much time trying > to get this to work and realized the function where SUDO_UID logic > resides doesn't even exist in a Windows build. Ahh, of course. I forgot that this patch sent into is_path_owned_by_current_uid(), as a UID as a value of some integer type is not a thing on Windows. OK, so it does need to be as you wrote to mean "not on Windows, and with 'sudo' that uses 'SUDO_UID' to record from whom 'root' came". OK. >> > + * In the unlikely scenario this happened to you, and that is how you >> > + * got to this message, we would like to know about it by letting us >> > + * now with an email to git@vger.kernel.org indicating which platform, >> > + * you are running on and which version of sudo you used to see if we >> > + * can provide you a patch that would prevent this issue in the future. >> >> Nice. What message does the reporter see? > > when using `sudo git status` a rejection of access to the directory they own It may have been obvious to who wrote the above comment, but it was not, at least to me. >> > + */ >> > +static inline void extract_id_from_env(const char *env, uid_t *id) >> > +{ >> > + const char *real_uid = getenv(env); >> > + >> > + /* discard anything empty to avoid a more complex check below */ >> > + if (real_uid && *real_uid) { >> > + char *endptr = NULL; >> > + unsigned long env_id; >> > + >> > + errno = 0; >> > + /* silent overflow errors could trigger a bug below */ >> >> What "bug" are we referring to? > > All of them, the ones we decided to ignore because they are irrelevant > when running as root, and the ones that are documented in the long > paragraph above. Likewise. It did not click "a bug below" referred to "your sudo is behaving in a way different from what we expected". Thanks.
diff --git a/Documentation/config/safe.txt b/Documentation/config/safe.txt index 6d764fe0cc..dba9d5b2d1 100644 --- a/Documentation/config/safe.txt +++ b/Documentation/config/safe.txt @@ -26,3 +26,13 @@ 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, in a platform that provides sudo and is +not Windows, it will check first if it might have been started through +it, and if that is the case, will use the uid of the user that invoked +sudo instead. +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. diff --git a/git-compat-util.h b/git-compat-util.h index 63ba89dd31..754cd90d43 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -393,12 +393,64 @@ static inline int git_offset_1st_component(const char *path) #endif #ifndef is_path_owned_by_current_user + +#ifdef __TANDEM +#define ROOT_UID 65535 +#else +#define ROOT_UID 0 +#endif + +/* + * This helper function overrides a ROOT_UID with the one provided by + * an environment variable, do not use unless the original user is + * root or could be used as means to escalate to root privileges. + * + * PORTABILITY WARNING: + * This code assumes uid_t is unsigned because that is what sudo does. + * If your uid_t type is signed and all your ids are positive then it + * should all work fine, but need to make sure sudo never generates a + * value higher than what can be represented by your uid_t type or a + * negative value or it will trigger wraparound bugs. + * + * If that happens the uid used might be incorrect and then trigger + * an access error from the filesystem itself. + * + * In the unlikely scenario this happened to you, and that is how you + * got to this message, we would like to know about it by letting us + * now with an email to git@vger.kernel.org indicating which platform, + * you are running on and which version of sudo you used to see if we + * can provide you a patch that would prevent this issue in the future. + */ +static inline void extract_id_from_env(const char *env, uid_t *id) +{ + const char *real_uid = getenv(env); + + /* discard anything empty to avoid a more complex check below */ + if (real_uid && *real_uid) { + char *endptr = NULL; + unsigned long env_id; + + errno = 0; + /* silent overflow errors could trigger a bug below */ + env_id = strtoul(real_uid, &endptr, 10); + if (!*endptr && !errno) + *id = env_id; + } +} + static inline int is_path_owned_by_current_uid(const char *path) { struct stat st; + uid_t euid; + if (lstat(path, &st)) return 0; - return st.st_uid == geteuid(); + + euid = geteuid(); + if (euid == ROOT_UID) + extract_id_from_env("SUDO_UID", &euid); + + return st.st_uid == euid; } #define is_path_owned_by_current_user is_path_owned_by_current_uid diff --git a/t/t0034-root-safe-directory.sh b/t/t0034-root-safe-directory.sh index 2e4492a66d..ecd9dca6b3 100755 --- a/t/t0034-root-safe-directory.sh +++ b/t/t0034-root-safe-directory.sh @@ -29,7 +29,7 @@ test_expect_success SUDO 'setup' ' ) ' -test_expect_failure SUDO 'sudo git status as original owner' ' +test_expect_success SUDO 'sudo git status as original owner' ' ( cd root/r && git status &&
bdc77d1d685 (Add a function to determine whether a path is owned by the current user, 2022-03-02) checks for the effective uid of the running process using geteuid() but didn't account for cases where that user was root (because git was invoked through sudo or a compatible tool) and the original uid that repository trusted for its config was no longer known, therefore failing the following otherwise safe call: guy@renard ~/Software/uncrustify $ sudo git describe --always --dirty [sudo] password for guy: fatal: unsafe repository ('/home/guy/Software/uncrustify' is owned by someone else) Attempt to detect those cases by using the environment variables that those tools create to keep track of the original user id, and do the ownership check using that instead. This assumes the environment the user is running on after going privileged can't be tampered with, and also adds code to restrict that the new behavior only applies if running as root, therefore keeping the most common case, which runs unprivileged, from changing, but because of that, it will miss cases where sudo (or an equivalent) was used to change to another unprivileged user or where the equivalent tool used to raise privileges didn't track the original id in a sudo compatible way. Because of compatibility with sudo, the code assumes that uid_t is an unsigned integer type (which is not required by the standard) but is used that way in their codebase to generate SUDO_UID. In systems where uid_t is signed, sudo might be also patched to NOT be unsigned and that might be able to trigger an edge case and a bug (as described in the code), but it is considered unlikely to be triggered, and even when it does the code would just safely fail, so there is no attempt either to detect it or prevent it in the code, which might need to be changed in the future. Reported-by: Guy Maurel <guy.j@maurel.de> Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Helped-by: Randall Becker <rsbecker@nexbridge.com> Helped-by: Phillip Wood <phillip.wood123@gmail.com> Suggested-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> --- Documentation/config/safe.txt | 10 +++++++ git-compat-util.h | 54 +++++++++++++++++++++++++++++++++- t/t0034-root-safe-directory.sh | 2 +- 3 files changed, 64 insertions(+), 2 deletions(-)