按道理不是用户变量在系统变量前面的吗？现在在我电脑，不管是 git bash ，powershell 还是 cmd ，输出的 path 都是系统变量在用户变量前面
 |
1
Melting 6 天前
我测试自己的电脑，看起来应该是 path 是系统>用户，其他的是用户>系统
|
 |
2
xtreme1 6 天前
Path=%Path%(System);%Path%(User)
|
 |
4
jifengg 6 天前
一直没注意这个事情，看了我的，是系统在前面。所以你的没错。
|
 |
5
body007 6 天前
可以用 clink 或者 cmderr 在脚本中将你想要的环境变量放前面，类似下面这种，但只能生效到打开的 cmd 额。
 |
 |
6
skiy 6 天前
直接 echo $env:PATH 对比一下，看看是系统里配的在前还是在后就知道了。
|
 |
7
geelaw 6 天前  7
除了 PATH 以外都是用户先于系统，PATH 由 系统 > 用户 的顺序合成我不知道是什么时候开始的，但从 Vista 以来这个设计可以缓解一些 UAC 提权攻击。
假设 PATH 是 用户 > 系统 的顺序，那么在 Vista 上，管理员用户运行的非提权程序当然可以修改用户的 PATH ，这会导致重新登录后提权程序的 PATH 先搜索非提权程序指定的目录，是一种提权攻击的渠道。UAC 禁止提权的时候继承环境变量也是出于这个考虑。 反之，如果是 系统 > 用户，那么提权程序的 PATH 先搜索的目录只有提权时才能修改，不存在越权的问题。 如果提权程序搜索 PATH 的时候本来就无法从系统级 PATH 找到，那么这是提权程序的设计问题，无论哪种顺序都不安全，因此对决定 系统/用户 级别 PATH 谁优先不作贡献。 |
 |
8
yulon 6 天前
而且系统是即时生效，用户要重启 GUI shell (explorer.exe)，导致我从来不用用户
|
|
9
geelaw 6 天前 1
@yulon #8 explorer.exe 是会对 WM_SETTINGCHANGE "Environment" 作出反应的，如果你需要重启 shell 才有效，说明改变环境变量的进程忘记广播此消息。
|
 |
10
jim9606 5 天前 1
如果系统 PATH 优于用户 PATH ，可能是为了避免一些重要系统程序(cmd,rundll,regsvr32,explorer)被无需特权即可改写的用户 PATH 截胡用以实现恶意行为（邪恶女仆攻击），系统 PATH 排头的通常是需要特权读写的目录，无特权的话写不进去。这算是一种安全策略。
类似的还有 DLL 搜索顺序，特定几个 KnownDLLs(kernel32 、user32 、shell32 、WS2_32 等)优先在系统目录搜索。 |
 |
11
gogogo2000 5 天前
@jim9606 类似的还有 DLL 搜索顺序，特定几个 KnownDLLs(kernel32 、user32 、shell32 、WS2_32 等)优先在系统目录搜索
KnownDLLs 的信息是写在注册表中的，根本就不会搜索非系统文件夹，无论你怎么修改 path 都没有用 |
Select Language