umask 077的缺点？

限制umask为077的缺点是什么？许多发行版（我相信除了Red Hat以外的所有发行版）都在/ etc / profile中配置了默认umask 022。对于多个用户正在访问的非桌面系统来说，这似乎太不安全了，安全性值得关注。

与此相关的是，在Ubuntu上，用户的主目录也创建了755权限，安装程序指出这是为了使用户更易于共享文件。假设用户可以方便地手动设置权限以共享文件，那么这不是问题。

还有哪些其他缺点？

022使事情变得方便。077使得事情不太方便，但是根据情况和使用情况，它可能不会比必须使用方便sudo。

我会说，sudo与您对自己和用户造成的痛苦程度相比，您从中获得的实际的，可衡量的安全优势是微不足道的。作为一名顾问，我对我的观点不屑一顾，sudo并且挑战打破众多sudo设置的挑战，而我还没有花超过15秒钟的时间来做到这一点。你的来电。

知道umask是好事，但这只是“完整早餐”中的一个玉米片。也许您应该问自己：“在我使用默认配置之前，必须在所有安装之间保持一致性，并且需要记录下来并证明这些配置对那些精打细算的人来说是正确的，这将是什么？我？”

Umask也是一个内置的bash，可由单个用户在其外壳初始化文件（~/.bash*）中设置，因此您实际上并不能轻松地实施umask。这只是默认设置。换句话说，这并不能给您带来很多好处。

最明显的缺点是，当您开始在共享目录中创建文件/目录时，希望其他用户可以访问它们。

当然，在做需要被所有用户共享的工作之前，别忘了设置正确的umask。

另一个警告（一旦意识到，这并不是真正的缺点），当您开始做sudo时，例如安装本地程序，ruby gem，python egg（显然不是OS管理软件包），创建配置文件等等。

由于umask由sudo会话继承，因此您会遇到麻烦，因此只有root用户才能访问您创建的文件/目录。可以将sudo配置为以所需方式自动设置umask：superuser.com上涵盖了此问题。

如果您尝试控制其他用户可以互相看到的内容，则Umask不合适。但是，如果您拥有并处理大量对要求访问权限敏感的文件，而不仅仅是让人们看到他们想要的东西，那么它的麻烦/风险就不会那么麻烦/麻烦了，而不是077的umask是个好主意。

我管理的文件服务器上有一些敏感文件。我认为设置限制性umask然后使用定期脚本，也许是cron作业以对某些文件夹中的项目设置更特定的权限，这对我来说是一个理想的解决方案。设置好之后，我会在此回发，让您知道它的工作原理。

@ [伙计们猛击sudo]为此启动一个新线程，它可能需要多个线程，而该线程是关于umask的。

使用自己的安装系统的第三方应用程序可能具有关于系统默认umask的内置假设。

作为一个实际示例，在将umask设置为077的系统上更新Oracle 10数据库之后，同一系统上的应用程序无法访问数据库...因为数据库客户端必不可少的库以及该库的目录位于其中，现在已受到保护，以便只有oracle用户才能访问它们，这显然不是应该如何工作的。

事实证明，Oracle更新程序过程并未特别注意客户端库的权限将允许其他用户使用它们，而是基于这样的假设：更新程序添加的文件将使用umask 022创建，因此可以使用默认情况下。在chmod -R a+rX对适当的目录执行了一些明智的命令之后，一切都恢复了。

当然，可以通过将oracle帐户视为具有标准umask 022的特殊系统帐户，并将umask 077限制为只能实际登录的用户帐户来避免这种情况...但是我认为这是一个很好的例子，说明了如何“强化决策可能会带来无法预料的副作用。

.rpm并且.deb软件包为它们包含的任何文件携带明确的权限信息，因此它们通常不会出现此类错误的风险。

我的这条线 ~/.zshrc

umask 0077

全局设置它可能不是一个好主意，但是在rc文件中将其设置为默认值可能不会受到损害，甚至不会在/etc/skel/.rc文件中将其设置为默认值。全系统都会引起问题。

它将导致服务器出现问题。例如，当多个应用程序以不同的用户身份运行时，试图从不同的用户访问文件。像apache读取配置文件或pi孔读取dnsmasq.conf。只需在可能从中受益的用户上运行它，例如单个主目录，而无需在中显式设置/etc/profile。