标签: file-permissions

我对 Web 开发比较陌生，所以请耐心等待。

我主要是 iPhone 开发人员，但最近使用共享主机为其他人创建了一个站点。我可以在该站点上用 PHP 写入文件，而无需考虑权限。

我正在为我正在制作的新应用程序部署 Web 服务，但进展并不顺利。这里最重要的区别是我使用的是其他人的服务器，并且只有 FTP/DB 访问权限。

基本上，我有很多 PHP 文件构成了我的 CMS，如下所示：

mysite.com/admin/manage_news.php
mysite.com/admin/manage_events.php

然后这些脚本编辑数据库或文件。他们可以很好地与数据库交互，但是，我的脚本无法写入文件系统。例如，他们可能会尝试写入以下文件：

mysite.com/data/img/event_1.png
mysite.com/data/somefile.txt

这在我的 MAMP 安装（本地）上运行良好，但是一旦部署到服务器，每次尝试写入时 PHP 都会出现错误......

无法打开文件“../data/img/someimage.png”进行写入。

所以我给运行服务器的人发了电子邮件，他回来说：

它在公共许可下工作吗？(777)

而且，确实如此 - 但我对使用公共权限非常谨慎，因此立即再次禁用它。我给他发邮件说“我怎样才能让我的 PHP 脚本使用标准用户权限来编写”，他说：

把它公开，就没事了

我认为这是域解析中某处的 ip 冲突，但我并不担心。

然后我给他发电子邮件说“这肯定是不安全的”或类似的话，他回复如下：

现实情况是，有数百万个网站，包括我管理的几个网站，它们在各种文件夹中都有 777 个，这只是一种生活方式。

谁能给我一些我可以给他的解决方案的想法？或者我可以做些什么来避免使用 777？我真的不喜欢我的网站/服务上的任何文件夹都可以公开写入的想法。

我非常感谢您的建议，因为我对 Web 服务器知之甚少。

我想弄清楚为什么在etckeeper提交后，我在重启时遇到了问题（由于这个伟大的事情已经解决了）。

我和 etckeeper 一起玩，git checkout some_commit_sha快速浏览了一下，然后git checkout master.

/etc在这些操作之后，我的文件权限似乎被破坏了。包括所有文件ssh_host_rsa_key passwd-, shadow-均rw-r--r--。我不知道 Git 不保存文件权限。

现在我修复了所有这些（我希望我没有错过任何东西）。

获得/etc.

最近，我一直在与我们的一位存储人员合作开展一个项目，该项目涉及对公司多年来使用的大文件共享进行一些审查。通常，由于以下一种或多种原因，我们会遇到无法访问的目录或文件（使用域管理员帐户）：

• 损坏的 ACL
• Administrators 组（或 SYSTEM 用户）的访问权限已被撤销或拒绝
• 文件名 + 路径太长（超出MAX_PATH）

有一些工具可以在这些情况下提供帮助，它们来自 Microsoft（例如 TAKEOWN.EXE 和 ICALCS.EXE）或第三方（例如SETACL.EXE）。有时需要其他技巧，例如使用PSEXEC.EXE在 SYSTEM 帐户下运行命令之一。即使只是弄清楚要做什么和按什么顺序做也是一个挑战......

例如，我希望能够使用这样的流程对其进行故障排除：

1. 路径是否太长？如果是这样，请使用\\?\前缀构建路径，然后再次测试。
2. ACL 是否损坏？如果是这样，请正确重新排序 ACE 并删除任何未知数，然后再次测试。
3. 管理员组是否拒绝访问？如果是这样，请取得所有权，为 Administrators 组和 SYSTEM 帐户添加回权限，然后再次测试。
4. 它仍然失败吗？如果是，请删除所有 ACE 并仅应用继承的权限，然后再次检查。（这是最后的手段，因为它经常打开本应更具限制性的权限。）
5. 是目录吗？如果是这样，那么该过程需要对内部文件递归地继续......

当我们有数百个目录需要修复时，手动执行上述步骤很痛苦，而且不合理。我曾尝试编写脚本来帮助解决这些问题，但发现很难让脚本对其做出的决定“智能”，因此通常更容易执行粗略的修复方法，例如仅恢复继承的权限。

任何人都可以推荐其他有助于此过程的软件和/或脚本吗？或者，您如何解决此类权限问题？

在文件服务器上的共享文件夹上，对于安全选项卡下的域用户名对象，图标有一个红色的 x。

没有任何症状，用户具有完全访问权限，他们的名字图标上只有一个红色的 x。

为什么是这样？

为澄清起见，登录 windows 2008 r2 文件服务器，浏览到用户共享文件夹，右键单击该文件夹，点击属性，单击安全选项卡。代表用户域名的对象在图标的右下角有一个小红x，看起来像一个人。除了我之外，没有任何症状想知道为什么会有红色的 x。

更新：当您从工作站查看权限时，它不显示 x，仅在文件服务器上查看

背景

不能被剥夺服务器管理员权限的用户往往会忘记，当他们将数据库备份 ( .bak)保存C:在驱动器上并填充驱动器时，他们会输得很惨。

题

是否可以阻止服务器管理员用户将某些类型的文件保存在目录中C:？他们仍应被允许在 上保存任何其他文件类型C:，并且他们对所有其他驱动器的权限应保持不变。

选择

如果不可能只禁止某些文件类型，那么每次有人尝试将.bak文件保存在某些目录中时，C:是否至少可以显示一个弹出警告？

其他注意事项

1. 出于各种原因，这些用户必须保留其服务器管理员权限。

2. 我不介意我使用的是文件级权限、脚本还是 GPO。欢迎所有有效的解决方案。

我正在使用各种 SFTP 客户端将文件上传到 SFTP 服务器，但在放置文件时使用的默认权限有问题。

当请求放置文件时，SFTP 客户端（例如 WinSCP 或 Filezilla）将发送 SSH_OPEN 命令，而不请求任何显式文件权限。

另一方面，Linux（Red Hat 和 Ubuntu）上的 OpenSSH sftp 命令似乎正在等待 SSH_OPEN 命令以及“640”模式。

如何配置 OpenSSH 命令以不显式设置文件模式，或者如何将其配置为发送 640 以外的模式？

非常感谢！

更新：

我检查了 OpenSSH sftp 客户端源代码，看起来 OpenSSH sftp 将始终尝试保留文件模式，即使未设置 -P： http ://www.koders.com/c/fidD3B20680F615B33ACCB42398FAAFEE1C007DF942.aspx?s=rsa#L986

为了解决这个问题，我使用了 Putty SFTP 客户端。

在/var/log/nginx/我有访问和错误日​​志。有些是.log错误，有些是.gz

我想我搞砸了权限。有些文件是由root/root创建的，其他文件是使用nginx.conf 中配置的用户创建的，等等。

• 哪个用户/组应该创建这些文件？为什么？可以root吗？我可以看到现在 root 正在创建新的 .log 文件，但不确定它是否正确。
• 我还想问在哪里更改创建这些文件的用户？

包管理器Homebrew（我在 OS X 上，但我对基于 Unix 的安全性一般很好奇，因为它与目录权限有关）将所有者设置/usr/local/bin为我的用户（root默认情况下，对吗？），这意味着现在我可以通过简单地将它们移动到/usr/local/bin（sudo不需要）来安装可执行文件。

1. 我对此是否正确，通常/usr/local/bin归root?
2. /usr/local/bin与您的普通用户交流是不是一个巨大的安全问题，因为现在我运行的任何软件都可以代表我安装程序而无需我的密码？

出于某种原因，当我尝试保存文件（由 PHP 在 下生成/www/appname/module）时 - 它保存在

/tmp/systemd-private-015eb2e9f67b4eef862c68e99fe0ba30-apache2.service-9h6i08

当瞄准文件保存在

/tmp/somename

文件保存在

/tmp/systemd-private-015eb2e9f67b4eef862c68e99fe0ba30-apache2.service-9h6i08/tmp/somename.

如何禁用此功能并“定期”将文件保存到 /tmp 目录？

无论如何，此默认功能的目的是什么？

首先，我在一家公司工作，很久以前当他们为每个部门实施文件共享时，他们也打破了 NTFS 权限的基本规则，并对某些文件夹的用户使用了显式权限。举一个我们设置的例子，每个用户都有一个 W: 驱动器。W: 驱动器层次结构类似于以下内容：

女：\人力资源

W:\法律

W:\财务

W:\通讯

我一度很确定，这些文件夹组织得很好。但随后出现了一个复杂的情况，即法律部门的某人需要访问人力资源文件，财务部门的某人需要访问法律文件，还有一些奇怪的情况，来自不同法律部门的 2 个不同的人需要访问法律文件夹中的特定文件夹，但他们不希望其他任何人访问此文件夹。IT 部门当时认为最好的解决方案是向这些人授予明确的权限。

自从我 7 年前开始从事这项工作以来，我一直在暗示为这些实例创建安全组（即使它只为一个用户帐户），因为当用户离开时，我们从所有组中删除它们，并将它们放入前员工 OU 5 年，但他们的明确权限仍保留在文件共享中的文件夹上。

当我暗示要为这些实例创建安全组时，相反的论点是，“当人们离开时，我们将如何管理所有空组？我们将如何在 AD 中组织和命名这些组？”

对于第一个参数，我建议使用一个简单的 powershell 脚本来删除空组，或者只是将它们保留在原位，以供未来要求对特定文件夹具有相同访问权限的员工使用。

不过，第二个论点是我在想出一个好的解决方案时遇到了麻烦。因此，在那篇简短的小说之后，我只想在面对我上面列出的情况时询问有关在 AD 中组织安全组以获得 NTFS 权限的任何提示或示例。

我的一个想法是为特殊的 NTFS 权限组创建一个 OU，以它们授予访问权限的文件夹命名这些组，并将完整的文件路径放在描述中。

如果有人有更好的想法，或者有人以不同的方式这样做，我愿意接受建议。