覆盖的HOME变量

我最近得知〜指的是HOME变量。所以，如果我设置HOME =/foo和再尝试使用bash脚本，想CD〜/文稿它结束了一句话：覆盖的HOME变量

富/文件：没有这样的文件或目录

什么是最好的做法在这个情况下？崩溃并向用户抱怨他们覆盖了HOME？或者有什么方法可以恢复HOME的默认值？

2017-03-17 Ryan Farber

这取决于上下文。对于许多工具来说，环境变量构成了接口的一部分（例如'LC_ *'和locales），并且您希望允许用户明确地设置它们。在其他情况下，比如'sudo'，你想清除环境以防止发生意想不到的事情。你在做什么你的脚本？ –

如果他们更改了“HOME”，那意味着他们希望应用程序将该目录作为其主目录。超越他们的意愿不是你的责任。 – Barmar

另一个恢复选项是使用'$ USER'在标准位置测试'/ home/$ USER'，如果你想恢复'$ HOME'，那么这个选项就可以使用。现在明白了，这些都不能在脚本中完成并影响shell。您可以更改脚本运行的进程的环境，但不更改父级。因此，如果用户在脚本中更改'$ HOME'，请使用@ Barmar的评论。 –

我认为你应该像对待任何其他访问文件的问题一样对待它。如果您尝试访问的文件不存在，或者您尝试在目录中创建文件，但无法打印该文件，则会显示一条错误消息。如果它对应用程序的操作至关重要，则在报告错误后退出。

据我所知，大多数需要使用用户主目录的应用程序只使用HOME环境变量，他们不会再次猜测它。

这不应该有任何安全隐含的。用户仍然需要适当的权限才能访问这些文件，因此重定向HOME将不允许他们编写他们不应该的文件。如果您的应用程序是set-uid，那么在打开用户目录中的文件时应始终返回到用户的ID，而不要使用提升的权限。

来源

2017-03-17 01:19:45 Barmar

用户主目录的真实来源是/etc/passwd，其中包含系统中每个用户的一行，列出用户的名称，主目录和其他信息。如果你的问题是“什么是某某这样的主目录？”，那么你应该看看它在/etc/passwd。*

然而，尽管/etc/passwd是正确的，如果用户已经重挫$HOME一些其他的路径，他们可能希望您使用该值而不是“真正的”主目录。除非允许用户欺骗主目录存在安全问题，否则最好盲目使用用户给出的值。

就个人而言，我会检查$HOME是否是一个目录（例如if [[ -d "$HOME" ]]），如果是这样，请按原样使用它。如果不是，则使用grep和cut解析出/etc/passwd，可能会将警告打印到stderr以提醒用户他们的$HOME不好。你可以grep找到由id -u打印的UID，这个不能被非root用户破坏。

但是，如果你真的担心$HOME被破坏，你还应该担心$PATH，$LC_*变量和其他几个可能破坏各种事物的环境变量。最终，仅仅假设这些变量是正确的并且按原样使用它们会更容易，除非存在安全问题。这意味着只是一味地使用$HOME，不要太担心它是错误的。

*在使用LDAP或类似联网系统管理帐户的系统上，用户的帐户可能没有在那里列出。在某些情况下，有一个/etc/passwd.cache或类似的东西，可能包含用户，但不能保证在每个系统上都能正常工作。在whoami(1)上运行strace(1)可以帮助指示此信息来自何处。

来源

2017-03-17 00:51:28 Kevin

'/ etc/passwd'中的哪一行？他们也可以覆盖'$ USER'和'$ LOGNAME'。 – Barmar

@Barmar：谢谢，修正。 – Kevin

可以有多个用户使用同一个uid。用户名在登录时用来选择所需的'/ etc/passwd'行。我认为'whoami'在'/ var/run/utmp'中查找来查找与当前终端相关的用户名。 – Barmar

覆盖的HOME变量

回答

相关问题