目前,我有一个运行网站的基本 Ubuntu 服务器。该网站供一些学习 HTML/PHP 的学生使用,每个学生都有自己的帐户,并带有指向共享网站文件夹的符号链接。由于学生们一起开发网站,因此每个用户都需要能够修改所有文件(例如 index.html)。因此,我创建了一个 Webdev 组,其中包含所有学生,并在他们的 .bashrc 中设置了默认 umask 0002(这允许新创建的文件为 774)。共享文件夹由 Webdev 组拥有,chmod g+s 使新文件/文件夹也属于 Webdev 组。
问题是学生们使用的是 IDE(Coda 2),当他们使用 IDE 创建新文件或文件夹时,文件在服务器上的权限为 644(非组可写)。但是,当我通过连接 Cyberduck(SFTP 客户端)创建新文件时,文件权限为 664(应该是这样的)。所以我不明白为什么 Coda 会有所不同。
但是,经过反复尝试,我认为 Coda 首先在本地磁盘上创建文件,然后将该文件上传到服务器。在 Mac 上,默认情况下,新创建的文件大小为 644。当客户端上传已经是 644 的文件时,它在服务器端仍保持为 644(umask 在这种情况下没什么用)。我也尝试为该文件夹创建 ACL 权限,但通过 SCP 从我的 Mac 上传的文件没有获得默认的 ACL 权限。
在 Coda 中,有一个选项可以更改传输的文件权限。但是,此选项似乎将 chmod 应用于所有正在上传或保存的文件。当其中一名学生在尝试上传或保存文件时修改其他人创建的文件时,Coda 也会尝试执行 chmod,但会失败,因为该用户不是该文件的所有者。
我目前的解决方案是使用 bindfs... 我挂载共享的 Web 文件夹,然后 bindfs 设置新创建文件的权限和组所有权。但是,bindfs 似乎有点慢,我相信有更好的解决方案。
即使学生放弃 Coda 2 并使用带有 scp 的 Mac vim,服务器上新创建的文件的行为也会相同 (644),这是 Mac 上的默认行为。
其他选项...
1) 我教学生在 IDE 中使用(ssh/chmod)来更改上传时自己的文件权限。
2)我让所有学生的 Mac 都具有默认的 umask 0002,这样就可以使用正确的权限上传文件。
3)每5到15分钟编写一个corn脚本来修复文件权限......(如果学生们同时一起工作,我认为这个选择是最糟糕的)。
有什么方法可以让所有通过 SCP 上传的文件都具有默认文件权限 664,即使上传的文件具有较低的权限?(经过几个小时的搜索,我认为这是不可能的)我猜 corn 脚本是新手用户的最佳选择。Web 开发人员如何在大型网站上协同工作?
还有类似的东西:https://serverfault.com/questions/395418/managing-linux-directory-permissions-sftp
答案1
Coda 实际上上传的是本地文件。除非你使用现在不受支持/过时的黑客工具http://sftpfilecontrol.sourceforge.net,文件将具有它们在本地拥有的任何权限。由于 OSX 的 umask 为 022,因此在 OSX 上创建的文件不是组可写的,因此是 644。Coda 很乐意上传它。正如您所发现的,Coda 可以强制特定权限,但它不够细粒度,无法指定只应对新文件执行此操作,因此在保存不属于用户的现有文件时会出错(这是最常见的情况)。我让它工作的唯一方法是更改 OSX 上的用户 umask。创建文件/etc/launchd-user.conf
并放入其中:
umask 002
然后重启。之后,Coda 在本地创建 664 个文件,并上传它们。现在文件可以正确地进行组写入,并且不需要设置上传权限Coda 首选项中的选项。
答案2
在 Coda 首选项面板的“规则”选项卡下,似乎可以设置通过 ftp/sftp 上传的文件所需的权限。默认值为 644;似乎只需选中“组”行中的“写入”框即可解决问题。当然,每个学生都必须在自己的 Coda 副本中执行此操作。
答案3
问题不在于文件的权限,而在于学生所属的组。在 Web 服务器计算机上,如果您将每个学生的主要组设置为与 Web 服务器的组相同(在 Linux 系统上通常是 www-data 或 apache),并在 Coda 首选项窗格中将默认文件权限设置为 660,那么一切都应该没问题。
# usermod -g apache studentUID
或者
# usermod -g www-data studentUID
取决于您在 Web 服务器上运行的是哪种版本的 Linux。