对 mkdir 创建的目录的奇怪权限（不执行）答案

【问题标题】：Strange permissions on directory created by mkdir (no execution)对 mkdir 创建的目录的奇怪权限（不执行）
【发布时间】：2014-01-01 05:21:43
【问题描述】：

我有这个旧的 Perl 脚本。该脚本在 CentOS 6.4 上通过 cron 运行。它会创建一个临时目录并尝试在那里解压缩文件。

这是一段代码：

$lg->li("Creating Directory... \n\t$unzip_dir");
mkdir ($unzip_dir, 0777) or my_die("mkdir $unzip_dir failed") unless (-e $unzip_dir && -d $unzip_dir);

但是执行后目录有奇怪的权限：

drwxrwsr-x 42 buser     agroup  12K Dec 30 09:18 .
drwxrwsr-x  4 buser     agroup 4.0K Apr  6  2012 ..
drw-rwSr--  2 auser     agroup 4.0K Dec 28 11:51 tm_unpack_dir_1388412502.20184

用户 auser 的 umask 是 0002。

为什么新目录没有执行权限？任何想法，这是怎么发生的？

【问题讨论】：

那个 umask 不会产生这些权限。您是否尝试codnodder's suggestion 打印 umask？另请注意，可以通过在脚本中调用 umask EXPR 来更改 此进程 的 umask。
@ThisSuitIsBlackNot 是的，我做到了。脚本的回复是 0002。脚本内部没有明确的“umask”调用。
@ThisSuitIsBlackNot 我无法重现结果。即使是脚本也不总是会创建如此奇怪的目录。大多数时候它工作正常。
你应该在你的问题中这么说。如果这是一个间歇性问题，那么（显然）正在发生其他事情。也许您稍后在脚本中调用chmod，或者在创建目录后另一个脚本正在更改权限。您提供的信息不足以调试您的问题，因此您需要缩小可能性。
就像我说的，肯定有其他事情发生。它甚至可以是完全不同的脚本。由于这是一个间歇性问题，您需要弄清楚故障之间的共同点。权限是否仅在一周中的某些时间或某些日子被搁置？重启后？当独角兽在你的隔间撒上仙尘？我不熟悉你的设置，所以我不能说更多，除了 0002 + mkdir 的 umask 单独不会导致这些权限（正如你自己看到的那样）。

标签： linux perl cron centos6

【解决方案1】：

奇怪的权限是由父目录上的 setgid 位结合不寻常的 umask 引起的：

看父目录的权限，第一行：

drwxrwsr-x 42 buser     agroup  12K Dec 30 09:18 .
drw-rwSr--  2 auser     agroup 4.0K Dec 28 11:51 tm_unpack_dir_1388412502.20184

注意它有rwxrwsr-x，这意味着setgid 位已设置。目录上的 setgid 位会导致在目录中创建与目录相同的组的新文件。新目录inherit the setgid bit from their parent。

0113 的 umask 会导致您看到奇怪的权限。那是一个不寻常的umask，默认是0022。 umask 设置在执行脚本的环境中，或者直接设置在脚本本身中。

不要担心脚本中mkdir 之后的0777：mkdir $dir, 0777 表示“创建 $dir 而不会干扰当前的 umask”。 0777is the default and can be safely omitted.

直接在您的脚本中尝试setting the umask：

umask 0022;
$lg->li("Creating Directory... \n\t$unzip_dir");
mkdir ($unzip_dir) or my_die("mkdir $unzip_dir failed") unless (-e $unzip_dir && -d $unzip_dir);

应该导致：

drwxrwsr-x 42 buser     agroup  12K Dec 30 09:18 .
drwxr-sr-x  2 auser     agroup 4.0K Dec 28 11:51 tm_unpack_dir_1388412502.20184

新建目录权限为rwxr-sr-x，比较正常。请注意，由于父目录，setgid 位仍然设置。

哦，您可能想知道为什么 setgid 位有时是小写的 's' 有时是大写的 'S'。这取决于executable bit。小写s 表示executable bit 已设置，大写表示未设置：

$ mkdir foo
$ ls -l
drwxr-xr-x 2 johan johan 4096 Dec 30 17:22 foo
$ chmod g+s foo
$ ls -l 
drwxr-sr-x 2 johan johan 4096 Dec 30 17:22 foo
$ chmod g-x foo
$ ls -l 
drwxr-Sr-x 2 johan johan 4096 Dec 30 17:22 foo

【讨论】：

其实这个用户的umask是0002。

【解决方案2】：

您的代码在我看来是正确的。

在我的系统上确认：

perl -e 'mkdir("foo", 0777);'

drwxr-xr-x  2 user  user     512 Dec 30 10:48 foo

mkdir 受您的umask 影响。一个时髦的 umask 可以做一些时髦的事情。

这对你有什么好处？

perl -e 'printf("%04o\n", umask());'

我明白了：

这就是为什么当我要求 0777 时我的文件夹被创建为 0755。

【讨论】：

【解决方案3】：

我已经调试了脚本并找到了问题的根源。由我们的一位提交者发送给我们的 tar.gz 存档引起的问题。这些 tar 文件的目录没有设置执行权限。我不知道他们是如何达到这样的结果的。

还有一个问题 - Gnu Tar 没有阻止恢复文件和目录权限的密钥。

因此，在提取具有错误权限的存档后，我必须递归地为存档中的所有文件和目录设置正确的权限。

谢谢大家。

【讨论】：

【解决方案4】：

表示已设置setuid和setgid位。

setuid（设置用户id）是一个权限位，允许用户以所有者的权限执行程序。

setgid（设置组id）是一个位，允许用户以组所有者的权限执行程序。

http://linuxg.net/how-to-set-the-setuid-and-setgid-bit-for-files-in-linux-and-unix/

【讨论】：

这些位是谁设置的？函数 mkdir ($unzip_dir, 0777) 明确设置权限为 0777。
这个答案具有误导性。问题是关于目录，而不是文件。目录的 setuid 和 setgid 有 a different meaning