//更新2月8日 – 突出问题简述：
我们的情况
我们公司的几个人login到服务器并上传文件。 他们都需要能够上传和覆盖相同的文件。 他们有不同的用户名，但都是同一组的一部分。 但是，这是一个互联网服务器，所以“其他”用户应该（一般来说）只读访问。 所以我想要的是这些标准的权限：
文件：664
目录：771
我的目标是所有用户不需要担心权限。 服务器的configuration方式应使这些权限适用于新创build，复制或覆盖的所有文件和目录。 只有当我们需要一些特殊的权限，我们会手动改变这一点。
我们通过Nautilus中的SFTP将file upload到服务器，通过使用sshfs挂载服务器并在Nautilus中像访问本地文件夹一样访问它，并通过命令行中的SCP进行访问。 这基本上涵盖了我们的情况和我们的目标。
现在，我读了许多关于美丽的umaskfunction的东西。 从我所了解的umask（和PAM一起） 应该让我做到我想要的：为新的文件和目录设置标准的权限。 但是，经过了许多个小时的阅读和反复试验，我仍然没有得到这个工作。 我得到许多意想不到的结果 我真的很想搞好umask，还有很多问题没有答案。 我将在下面发表这些问题，以及我的调查结果和对导致这些问题的试验的解释。 鉴于很多事情似乎出了问题，我认为我做了几件事情是错误的。 因此，有很多问题。
注：我使用的是Ubuntu 9.10，因此无法更改sshd_config以设置SFTP服务器的umask。 已安装SSH OpenSSH_5.1p1 Debian-6ubuntu2 <必需OpenSSH 5.4p1。 所以在这里去回答问题。
1.我是否需要重新启动PAM CHANGS才能生效？
我们先从这个开始。 有太多的文件涉及，我无法弄清楚什么是什么，什么不影响事情，也因为我不知道是否必须重新启动整个系统PAM更改才能生效。 在没有看到预期的结果之后，我确实这样做了，但这真的有必要吗？ 或者我可以从服务器注销并重新login，并且新的PAM策略是否有效？ 还是有一些“PAM”程序来重新加载？
2.是否有一个单一的文件改变，影响所有会议的所有用户？
所以我最终改变了许多文件，因为我读了很多不同的东西。 我结束了在以下文件中设置umask：
~/.profile -> umask=0002 ~/.bashrc -> umask=0002 /etc/profile -> umask=0002 /etc/pam.d/common-session -> umask=0002 /etc/pam.d/sshd -> umask=0002 /etc/pam.d/login -> umask=0002 我希望这个改变适用于所有的用户，所以某种系统的改变是最好的。 可以实现吗？
来自“简明英汉词典”毕竟，这个麻烦事，它工作吗？
所以在将umask更改为0002后，我会运行testing。
———— ———– SCP
testing1：
scp testfile (which has 777 permissions for testing purposes) server:/home/ testfile 100% 4 0.0KB/s 00:00
我们来检查权限：
user@server:/home$ ls -l total 4 -rwx--x--x 1 user uploaders 4 2011-02-05 17:59 testfile (711)
更新：通过仅在pam.d / common-sessions中设置umask来修复（请参阅注释）
——— ———— SSH
testing2：
ssh server user@server:/home$ touch anotherfile user@server:/home$ ls -l total 4 -rw-rw-r-- 1 user uploaders 0 2011-02-05 18:03 anotherfile (664)
——– SFTP ———–
鹦鹉螺：sftp：// server / home /
从客户端复制并粘贴新文件到服务器（客户端上的777）
testing3：
user@server:/home$ ls -l total 4 -rwxrwxrwx 1 user uploaders 3 2011-02-05 18:05 newfile (777)
通过Nautilus创build一个新文件。 在terminal中检查文件权限：
testing4：
user@server:/home$ ls -l total 4 -rw------- 1 user uploaders 0 2011-02-05 18:06 newfile (600)
我的意思是……这里刚刚发生了什么？ 我们应该每一次得到644。 相反，我得到了711,777,600，然后是644.而644只能通过SSH创build一个新的空白文件，这是最不可能的情况。
所以我问，umask / pam究竟工作？
更新：通过仅在pam.d / common-sessions中设置umask来修复testing4（请参阅注释）
那么它对UMASK SSHFS意味着什么呢？
有时我们使用sshfs在本地安装服务器。 很有用。 但是，我们又遇到了权限问题。
这里是我们如何挂载：
sshfs -o idmap=user -o umask=0113 user@server:/home/ /mnt
注意：我们使用umask = 113，因为显然sshfs是从777开始的，而不是从666开始的，所以我们得到了664，这是所需的文件权限。
但现在发生的是，我们看到所有的文件和目录，就好像它们是664.我们在Nautilus中浏览到/ mnt和：
那么让我们来看一下命令行：
user@client:/mnt$ ls -l total 8 -rw-rw-r-- 1 user 1007 3 Feb 5 18:05 copyfile (664) -rw-rw-r-- 1 user 1007 0 Feb 5 18:15 newfile (664) drw-rw-r-- 1 user 1007 4096 Feb 5 18:15 newfolder (664)
但是，嘿，我们来检查一下服务器端的这个文件夹：
user@server:/home$ ls -l total 8 -rwxrwxrwx 1 user uploaders 3 2011-02-05 18:05 copyfile (777) -rw------- 1 user uploaders 0 2011-02-05 18:15 newfile (600) drwx--x--x 2 user uploaders 4096 2011-02-05 18:15 newfolder (711)
什么？！ REAL文件权限与我们在Nautilus中看到的大不相同。 那么这个在sshfs上的umask只是创build一个显示不真实的文件权限的“filter”？ 而我试图从另一个用户打开一个文件，但具有真正的600权限，但644'假'的权限，我仍然不能读这个，所以这个filter有什么好处？
5. UMASK是关于文件的。 但是什么是董事？
从我的testing中，我可以看到正在应用的umask也以某种方式影响目录权限。 但是，我希望我的文件是664（002），我的目录是771（006）。 那么有可能有一个不同的目录的umask？
6. PERHAPS UMASK / PAM真的很酷，但是UBUNTU只是BUGGY？
一方面，我读了PAM / UMASK和Ubuntu成功的人的话题。 另一方面，在Ubuntu上我发现了许多关于umask / PAM / fuse的更新和更新的错误：
所以我不知道该怎么相信。 我应该放弃吗？ ACL能解决我所有的问题吗？ 或者我有再次使用Ubuntu的问题？
使用tar备份一个警告字。 Red Hat / CentOS发行版在tar程序中支持acls，但是Ubuntu在备份时不支持acls。 这意味着创build备份时，所有的acls都将丢失。
我非常愿意升级到Ubuntu 10.04，如果这也能解决我的问题，但首先我想了解正在发生的事情。
许多事情可能会在这里发生。
第一个想法：
/etc/pam.d/common-session是设置默认umask的最佳位置 .bashrc的任何条目覆盖， .bashrc只能在某些情况下读取（交互式，非loginshell） testfile (711)很奇怪
/home是如何安装的，你使用的是ACL吗？ ls -ld /home和getfacl /home打印了什么？） testfile已经存在，因为scp不会更改已经存在的文件的权限（除非使用-p标志） umask=0113可能会导致问题 umask可以被用户在.bashrc和.bash_profile覆盖。 更新：
umask=0113是错误的。
umask touch在安装点内创build一个新文件。 -rw-r--r-- ，没有x位 x位，你可能会破坏目录 解决方法：
如果我们想不出更好的办法，可以使用fam或gamin来监视正在创build的新文件并修改它们的权限，甚至只是定期运行的脚本，并在所有文件上设置权限。
这不是PAM / umask相关的，但它可能对你有用。
如果你设置了一个目录，那么其中创build的所有文件和目录都会自动分配给它的组。
root@ricarda ~ # mkdir hello root@ricarda ~ # chown :users hello root@ricarda ~ # chmod g+s hello root@ricarda ~ # ls -l |grep hello drwxr-sr-x. 2 root users 4096 Feb 7 04:05 hello root@ricarda ~ # touch hello/some_file root@ricarda ~ # mkdir hello/some_dir root@ricarda ~ # ls -l hello/ total 4 drwxr-sr-x. 2 root users 4096 Feb 7 04:16 some_dir -rw-r--r--. 1 root users 0 Feb 7 04:06 some_file
请仔细阅读这个解决scheme： 如何在Ubuntu 9.10的/ var / www中为多个用户编辑多个站点的权限结构？
ACL应该适合您。
在该组的所有文件夹上设置一个默认ACL，然后将被所有将来的文件和目录inheritance。
像setfacl -md:g:uploaders:rwx应该可以工作。
要修复您的现有权限：
find /shared/folder -type d -exec setfacl -md:g:uploaders:rwx {} \; find /shared/folder -type f -exec setfacl -mg:uploaders:rw {} \;
看起来，如果复制文件时设置了“保留”，则默认ACL不起作用。 在这种情况下，我只能build议在cron中运行find命令或者监视文件系统的变化。