git-bash.exe saves/loads config from wrong home-directory (When using 'run as')

[Radon8472]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.24.1.windows.2
cpu: x86_64
built from commit: 992f0773022527b1b0cb1e0c13aec97dd5248053
sizeof-long: 4
sizeof-size_t: 8

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?
  • Windows 10 - 64 Bit

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.18362.900]

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: CustomEditor
Custom Editor Path: C:\Windows\System32\notepad.exe
Path Option: BashOnly
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled
Enable Builtin Interactive Add: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

In the administrative users, everything is fine, in the "non-admin" causes problems.

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

git-bash

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

**I started the git-bash like this:**
- Open `cmd` using "Run as user"
- Enter Credentials of an NON-Administrative user
- run `git-bash`
- right-click (on git-bash-title bar) -> options
- change some options
- hit "save" button

• What did you expect to occur after running these commands?

  • I expect it should load/save the config in my users home-dir (c:\Users\MY_USER.minttyrc)
  • I expect $HOME should be HOME=/c/Users/MY_USER
  • I expect user-.gitconfig should be loaded from "c:\Users\MY_USER"

• What actually happened instead?

  • Git bash tried to save in the dir c:\windows\system32 what is not writeable as non-admin.
  • my $HOME /c/Windows/system32
  • no user-.gitconfig was loaded (is assume because it was looking in c:\windows\system32 for a .gitconfig which doesn`t exist

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

More Details:

my relevant env variables in the console BEFORE Starting git bash are

APPDATA=C:\Users\MY_USER\AppData\Roaming
HOMEDRIVE=C:
HOMEPATH=\Windows\system32
LOCALAPPDATA=C:\Users\MY_USER\AppData\Local
TEMP=C:\Users\MY_USER\AppData\Local\Temp
TMP=C:\Users\MY_USER\AppData\Local\Temp
USERNAME=MY_USER
USERPROFILE=C:\Users\MY_USER

In the git-bash env shows:

USERNAME=MY_USER
LOCALAPPDATA=C:\Users\MY_USER\AppData\Local
USERPROFILE=C:\Users\MY_USER
APPDATA=C:\Users\MY_USER\AppData\Roaming
HOME=/c/Windows/system32
HOMEPATH=\Windows\system32

So all variables are correct, only HOME and HOMEPATH are wrong

• I tried to manually set the HOME in first line of GIT_INSTALL_DIR\etc\profile to HOME="$(cygpath -u "$USERPROFILE")" Like suggested in https://stackoverflow.com/a/32233667/2377961
  • that results in:
    • a correct HOME - Variable, but git-bash still loads and saves config from the wrong directory
    • that users .gitconfig was loaded from "c:\Users\MY_USER" like expected
    • BUT git-bash.exe still loads and saves its config options from/to c:\windows\system32

[dscho]

I tried to manually set the HOME in first line of GIT_INSTALL_DIR\etc\profile to HOME="$(cygpath -u "$USERPROFILE")" Like suggested in https://stackoverflow.com/a/32233667/2377961

Could you try setting it in the User environment in your Windows' System Properties instead?

[Radon8472]

I tried to manually set the HOME in first line of GIT_INSTALL_DIR\etc\profile to HOME="$(cygpath -u "$USERPROFILE")" Like suggested in https://stackoverflow.com/a/32233667/2377961

Could you try setting it in the User environment in your Windows' System Properties instead?

There is no way to set it for all users via system envoirement, so that is no option for me.
But as test for you, I tried to set the HOME-Variable in a windows Console BEFORE i run git-bash but still the same result.
That means in this context the git bash yust takes the wrong homedir even it it was defined in the env that started this git-bash.

[dscho]

There is no way to set it for all users via system envoirement, so that is no option for me.

So you want all users to run Git Bash as administrator? That's... interesting.

But as test for you, I tried to set the HOME-Variable in a windows Console BEFORE i run git-bash but still the same result.

Right, unless you use setx, the change will be confined to that Console process' environment, and if you run Git Bash from the Start Menu, it is safely outside that realm.

[Radon8472]

So you want all users to run Git Bash as administrator? That's... interesting.

No, I want that each user runs its git-bash with his own home-directory.
So e.g. "User_a" should have c:\Users\User_a as Home, and "User_b" should have c:\Users\User_b as home.

But now it is that "User_a" has the desired home, but all other users have c:\windows\system32 as home, and that is the problem.
By the way, only "User_a" has the "Run bash Here" Shell-Extensions in WindowsExplorer, maybe that could be a reason for this problem.

[dscho]

But now it is that "User_a" has the desired home, but all other users have c:\windows\system32 as home, and that is the problem.

Well, now I am really curious what sets your environment this way:

HOMEDRIVE=C:
HOMEPATH=\Windows\system32

Because that is not correct. HOMEDRIVE and HOMEPATH are documented to point to the users' home directories, and in your case, they clearly don't. Maybe they got configured in your system environment by mistake? When I look into my System Properties>Environment, I do not see them defined explicitly, so I really think that Windows sets them (unless overridden).

[Radon8472]

Maybe they got configured in your system environment by mistake?

No, for this user nothing special is defined in System Properties>Environment (Only the stuff that is automatically defined when creating a new user in windows).
Is there a chance that this could be a special behavoir because I start the commandline using Run as User ?

[dscho]

Is there a chance that this could be a special behavoir because I start the commandline using Run as User ?

Most likely. Is there anything in the environment that indicates that it was launched via Run as User? If yes, we can use that to ignore HOMEDRIVE/HOMEPATH in that case.

[landstander668]

For what it's worth, I can reproduce the environment variable discrepancy when starting cmd.exe with Run as different user. Here's what I see when running the beastie normally.

C:\Users\adric.norris>set HOME
HOMEDRIVE=C:
HOMEPATH=\Users\adric.norris

When running as a different user (a non-domain account in this case) I get:

C:\Windows\System32>set HOME
HOMEDRIVE=C:
HOMEPATH=\WINDOWS\system32

Unfortunately I do not see any environment variables which would indicate that it was run in this manner.

[Radon8472]

Is there a chance that this could be a special behavoir because I start the commandline using Run as User ?

Most likely. Is there anything in the environment that indicates that it was launched via Run as User? If yes, we can use that to ignore HOMEDRIVE/HOMEPATH in that case.

I checked the env in both constelations, here is are the differences

Run as	Logged in User
HOMEPATH=\Windows\system32	HOMEPATH=\Users\User_a
-	LOGONSERVER=\LAPTOP
-	SESSIONNAME=Console
-	USERDOMAIN_ROAMINGPROFILE=LAPTOP

So I thing you could check if the SESSIONNAME equals Console.

But maybe the best way to avoid all this stuff ist when you yust try to set

HOME="$(cygpath -u "$USERPROFILE")"

And only use HOMEDRIVE and HOMEPATH when USERPROFILE is not set.
And I think this variable should exist in all Windows Environments above windows 2000.

[rimrul]

C:\Windows\system32>echo %SESSIONNAME%
RDP-Tcp#99

There are definitely other values than Console that should get the default treament.

[mfriedrich74]

Runas is also an executable. It has a /profile and /noprofile argument. You may want to check which version is executed in this case or what the default is. My assumption is that these two options are responsible/affect the seen behaviour.

…

On Thu, Jun 25, 2020, 10:13 AM Matthias Aßhauer ***@***.***> wrote: C:\Windows\system32>echo %SESSIONNAME% RDP-Tcp#99 There are definitely other values than Console that should get the default treament. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2709 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABZH5SBA3SRN5QB645ZEZJTRYNLPLANCNFSM4OENODPQ> .

[Radon8472]

Runas is also an executable. It has a /profile and /noprofile argument. You may want to check which version is executed in this case or what the default is. My assumption is that these two options are responsible/affect the seen behaviour.
…
On Thu, Jun 25, 2020, 10:13 AM Matthias Aßhauer @.***> wrote: C:\Windows\system32>echo %SESSIONNAME% RDP-Tcp#99 There are definitely other values than Console that should get the default treament. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2709 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZH5SBA3SRN5QB645ZEZJTRYNLPLANCNFSM4OENODPQ .

What @rimrul was posting is a value that is defined when you logon via remote-desktop.
But in my case it was that runas (when using rightclick on explorer) doesn't have a env variable defined for SESSIONNAME.

in my eyes it would be the best to Check in git-bash code if USERPROFILE is defined, before using HOMEDRIVE or HOMEPATH to build a home-path

[Radon8472]

As I see in mingw.c (the same code exists in mingw.c on git-for-windows too) the USERPROFILE variable is already checked in the code.
So an very easy bugfix would be to yust move the codeblock where USERPROFILE is used before the check for

if ((tmp = getenv("HOMEDRIVE")))

[rimrul]

git-wrapper.c would also need to be modified if we decide to change this.

[mfriedrich74]

I believe SESSIONNAME is a red herring: SESSIONNAME: Terminal servers only - for a terminal server session, SessionName is a combination of the connection name, followed by #S *essionNumber*. For a console session, SessionName returns "Console"

…

On Thu, Jun 25, 2020 at 1:18 PM Radon8472 ***@***.***> wrote: Runas is also an executable. It has a /profile and /noprofile argument. You may want to check which version is executed in this case or what the default is. My assumption is that these two options are responsible/affect the seen behaviour. … <#m_-907698444408155253_> On Thu, Jun 25, 2020, 10:13 AM Matthias Aßhauer *@*.***> wrote: C:\Windows\system32>echo %SESSIONNAME% RDP-Tcp#99 There are definitely other values than Console that should get the default treament. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2709 (comment) <#2709 (comment)>>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZH5SBA3SRN5QB645ZEZJTRYNLPLANCNFSM4OENODPQ . What @rimrul <https://github.com/rimrul> was posting is a value that is defined when you logon via remote-desktop. But in my case it was that runas (when using rightclick on explorer) doesnt have a env variable defined for SESSIONNAME`. in my eyes it would be the best to Check in git-bash code if USERPROFILE is defined, before using HOMEDRIVE or HOMEPATH to build a home-path — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2709 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABZH5SCZZ64FCUB77DHTDALRYOBIDANCNFSM4OENODPQ> .

[Radon8472]

I believe SESSIONNAME is a red herring: SESSIONNAME: Terminal servers only - for a terminal server session, SessionName is a combination of the connection name, followed by #S essionNumber. For a console session, SessionName returns "Console"

I aggree.
Because the code of git-wrapper.c says in a comment:

With roaming profiles: HOMEPATH is the roaming location and
USERPROFILE is the local location

That maybe means the Code should

• Check is env SESSIONNAME starts with "RDP-Tcp", (Or Maybe yust check if USERPROFILE is on the same drive like HOMEDRIVE )
  • if yes, they should use the existing code, where HOME is build from HOMEDRIVE or HOMEPATH
  • if NO, we have either a run as sitiation, or a local "console" session, and in that case USERPROFILE should be used

[mfriedrich74]

Hi, That would be wrong too. A roaming profile with home drive and homepath is not only used with RDP. It's the corporates implementation/decision (e.g. via group policies) whether that's being used or not. If it is, it may be used with local and remote sessions. Best regards,Mike

…

On Fri, Jun 26, 2020, 2:04 AM Radon8472 ***@***.***> wrote: I believe SESSIONNAME is a red herring: SESSIONNAME: Terminal servers only - for a terminal server session, SessionName is a combination of the connection name, followed by #S *essionNumber*. For a console session, SessionName returns "Console" I aggree. Because the code of git-wrapper.c say in a comment: With roaming profiles: HOMEPATH is the roaming location and USERPROFILE is the local location That maybe means the Code should - Check is env ``SESSIONNAME` starts with "RDP-Tcp", - if yes, they should use the existing code, where HOME is build from HOMEDRIVE or HOMEPATH - if NO, we have either a run as sitiation, or a local "console" session, and in that case USERPROFILE should be used — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2709 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABZH5SF6CHCXR2QVVKXBX73RYQ3ALANCNFSM4OENODPQ> .

[Radon8472]

I found some helpfull informations about HOMEPATH and HOMEDRIVE variables in a Stackoverflow article about meaning-variables-homedrive-homepath.
It explains why you can not realy trust on these variables.

They are set by explorer, that is the reason why they are not changed for all kinds of seconday logins. of services.

[dscho]

So the real question is: can we fix this at all?

[mfriedrich74]

I did some local tests (No RDP). Any use of runas /user:localhost\user cmd.exe resets HOMEDRIVE and HOMEPATH to the below in the new session: HOMEDRIVE=C: HOMEPATH=\WINDOWS\system32 The effect is the same, if the user running runas is admin or not, elevated or not and whether the target user is admin or not doesn't matter. It's always set to C:\WINDOWS\system32 The use of /noprofile or /profile makes no difference. Note, that runas.exe explicitly resets the variables, i changed the variable as a test and the change is not taken over into the child process. There is just one exception: Simple elevation in case the running user is already a non-elevated admin and starts a new elevated prompt via explorer. BTW. Win10 explorer does not offer me an option to run something as a dedicated user. It has only "Run as Administrator". I have to hold shift while right-clicking on an executable (not shortcut) to see "Run as different user". And even here it resets the variables to C:\WINDOWS\system32. My hunch is, this behavior is intentional. I just don't know why (security?).

…

On Fri, Jun 26, 2020 at 6:02 PM Radon8472 ***@***.***> wrote: I found some helpfull information on about HOMEPATH and HOMEDRIVE variables in a Stackoverflow article about meaning-variables-homedrive-homepath <https://stackoverflow.com/a/36392591/2377961>. It explains why you can not realy trust on this variables. They are set by explorer, that is the reason why they are not changed for all kinds of seconday logins. of services. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2709 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABZH5SAKZXO46HFA44K36V3RYULIBANCNFSM4OENODPQ> .

[native-api]

So the real question is: can we fix this at all?

https://github.com/git/git/blob/e870325ee8575d5c3d7afe0ba2c9be072c692b65/compat/mingw.c#L2572-L2594 needs to be fixed -- to either use USERPROFILE unconditionally, or e.g. ignore HOMEDRIVE/HOMEPATH if they expand to WINDIR.

This looks like new behavior since at least Win7. In WinXP, HOMEDRIVE/HOMEPATH were simply not set for secondary logons, so that code worked fine.

[dscho]

@mfriedrich74 good analysis!

@native-api I already ruled out the unconditional ignoring of HOME*, but the WINDIR idea might work well. Care to try your hand at a PR?

[native-api]

@native-api I already ruled out the unconditional ignoring of HOME*

Could you elaborate/link to why? I seriously think that HOMEDRIVE/HOMEPATH is so niche now that it can safely be ignored. If someone with an unusual setup and use scenario comes complaining, we can evaluate their scenario and see if it's worth supporting.

Besides, that code doesn't work with those envvars right anyway: it should also check HOMESHARE.

[Radon8472]

I think the post of @mfriedrich74 is the answer...
We where looking for a indicator to find out if we are in such a run as sitiation.

I think we only have to check it like this

if( $HOMEPATH =="\\WINDOWS\\system32" && $USERNAME != "System32") {
  // We have a run-as situation -> Build $HOME from $USERPRFILE
} else {
 // keep existing code and fill $HOME from $HOMEPATH and $HOMEDRIVE
}

[mfriedrich74]

The use of HOMEDRIVE/HOMEPATH is not a niche. It is pretty common in larger companies to define these in active directory to map to a network location (the users home drive). I find it very convenient that this way I have a working git setup on all computers that I logon to. No setup if I have to move to a new main computer (i admid, not happening that often). The config files are backed up too on the network location.

…

On Sat, Jun 27, 2020, 3:48 PM Radon8472 ***@***.***> wrote: I think the post of @mfriedrich74 <https://github.com/mfriedrich74> is the answer... We where looking for a indicator to find out if we are in such a run as sitiation. I think we only have to check it like this if( $HOMEPATH =="\\WINDOWS\\system32" && $USERNAME != "System32") { // We have a run-as situation -> Build $HOME from $USERPRFILE } else { // keep existing code and fill $HOME from $HOMEPATH and $HOMEDRIVE } — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2709 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABZH5SGZGDDT4YAE2S2FKN3RYZEKTANCNFSM4OENODPQ> .

[mfriedrich74]

My tests were a local non-domain environment. Next week I could run the same at work in our domain and with RDP. Unless someonelse has those covered already. On Sat, Jun 27, 2020, 7:44 PM Mike Friedrich <[email protected]> wrote:

…

The use of HOMEDRIVE/HOMEPATH is not a niche. It is pretty common in larger companies to define these in active directory to map to a network location (the users home drive). I find it very convenient that this way I have a working git setup on all computers that I logon to. No setup if I have to move to a new main computer (i admid, not happening that often). The config files are backed up too on the network location. On Sat, Jun 27, 2020, 3:48 PM Radon8472 ***@***.***> wrote: > I think the post of @mfriedrich74 <https://github.com/mfriedrich74> is > the answer... > We where looking for a indicator to find out if we are in such a run as > sitiation. > > I think we only have to check it like this > > if( $HOMEPATH =="\\WINDOWS\\system32" && $USERNAME != "System32") { > // We have a run-as situation -> Build $HOME from $USERPRFILE > } else { > // keep existing code and fill $HOME from $HOMEPATH and $HOMEDRIVE > } > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#2709 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABZH5SGZGDDT4YAE2S2FKN3RYZEKTANCNFSM4OENODPQ> > . >