在维护实习单位服务器的过程中&＃xff0c;偶然发现一个有350万文件的文件夹需要清理&＃xff0c;于是我习惯性执行了rm -rf ./*&＃xff0c;却在数秒后被告知“参数列表过长”。在一番折腾过后&＃xff0c;我终于通过取巧的办法完成了这一任务&＃xff0c;也随着相关内核源码的阅读&＃xff0c;了解到了关于Linux Shell的一些有趣特性。
本文原载于未命名小站&＃xff0c;由作者本人同步至知乎&＃xff0c;转载请注明原作者博客地址或本链接&＃xff0c;谢谢&＃xff01;
0x01
最初我以为是rm命令对文件数量存在限制&＃xff0c;但当我尝试ls ./*、touch ./*等命令都遇到这一问题之后&＃xff0c;我开始将注意力放在Bash本身上。也许是通配符的限制。
突然&＃xff0c;我想起来rm命令支持管道送入参数&＃xff0c;也许可以通过这样的办法变相完成任务。于是我在另一个目录做了个测试&＃xff1a;
$ touch 123-1
$ touch 123-2
$ echo "123-1 123-2" | xargs rm
这两个文件果然消失。
于是我尝试使用find将目录下面所有文件列出&＃xff1a;
find . -name "*" | more # 使用more避免350多万个文件把终端挤崩溃
find . -name "*" | wc -l # 大致了解文件个数
输出的文件个数与我通过ls -l命令输出的个数基本一致&＃xff0c;果然输出了所有文件。接下来要做的就是将这些文件送到rm中。
0x02
但事实并非如此简单&＃xff0c;当我执行以下命令&＃xff0c;以为可以一口气顺利删除所有文件的时候&＃xff0c;我傻眼了&＃xff1a;
$ find . -name "*" | xargs rm
rm: log: No such file or directory
rm: 20190601-110204.log: No such file or directory
... # 所有待删除文件均发生报错
我重新观察文件名&＃xff0c;发现文件名格式均为log yyyymmdd-hhmmss.log&＃xff0c;众所周知Bash靠空格分割参数&＃xff0c;文件名被传入rm的时候照着空格被截断&＃xff0c;成为了两个文件名&＃xff0c;难怪删除失败&＃xff01;
0x03
吸取教训&＃xff0c;我使用了一个新的参数&＃xff1a;
find . -name "*" -print0 | xargs -0 rm
注意这一参数里的-print0与-0&＃xff0c;这是为了区分空格与分界符&＃xff0c;加入参数后此前用于分隔参数的空格&＃xff08;0x0a&＃xff09;则会变成NUL&＃xff08;0x00&＃xff09;&＃xff0c;这一参数的效果可以通过16进制查看器体现&＃xff1a;
$ ls
123 321
123 322
$ find . -name "12*" > 1.log
$ find . -name "12*" -print0 > 2.log
$ hexdump -C 1.log
00000000 2e 2f 31 32 33 20 33 32 31 0a 2e 2f 31 32 33 20 |./123 321../123 |
00000010 33 32 32 0a |322.|
00000014
$ hexdump -C 2.log
00000000 2e 2f 31 32 33 20 33 32 31 00 2e 2f 31 32 33 20 |./123 321../123 |
00000010 33 32 32 00 |322.|
00000014
可以发现在两个不同输出模式下&＃xff0c;分隔符不一样。默认的分隔符与空格一致&＃xff0c;即0x0a&＃xff0c;但当开启-print0模式后&＃xff0c;分隔符变成了0x00&＃xff0c;配合管道接收端的-0参数将NUL字符正确解析成参数定界符&＃xff0c;则可以完成带空格文件名的正常解析。
解决了这一问题&＃xff0c;我们再次执行&＃xff0c;问题随即解决。
0x04
过了两天&＃xff0c;又有一台服务器需要删除大量文件&＃xff0c;且领导要求只删除文件不删除里面的目录&＃xff0c;我一看&＃xff0c;又是400多万个文件。但在之前的折腾过程中&＃xff0c;我早有准备。
find命令默认开启递归模式&＃xff0c;如果只删除文件不删除目录&＃xff0c;只需要配置递归深度为1即可&＃xff1a;
find . -maxdepth 1 -name "*" -print0 | xargs -0 rm
执行命令后再执行ls -l&＃xff0c;发现问题果然解决&＃xff0c;所有目录完好无损。
0x05
快速解决完问题后&＃xff0c;我一看离下班还有好一阵子&＃xff0c;便开始琢磨Bash内通配符的长度限制到底从哪来。
我首先找了另一个有大量文件的目录开始实验&＃xff0c;换用zsh进行ls ./*操作&＃xff0c;得到的确是一样结果。看来该长度限制与Bash无关。
我突然想起来曾经看过的一个安全类视频&＃xff1a;Youtube - Bash injection without letters or numbers - 33c3ctf hohoho (misc 350) - LiveOverFlow&＃xff0c;其中解释了通配符&＃xff08;Wildcard&＃xff09;的原理。
当我们输入*的时候&＃xff0c;Shell所做的是列举出满足通配符规则的所有文件&＃xff0c;并以空格分割&＃xff0c;然后送进Shell。举例而言&＃xff0c;如果你有一个全是txt文件的目录&＃xff0c;你直接执行*&＃xff0c;就会发现以下错误&＃xff1a;
$ touch abc.txt
$ touch bbc.txt
$ *
bash: command not found: abc.txt
$ echo *
abc.txt bbc.txt
相信看到这里&＃xff0c;大家都明白通配符的行为以及为什么上述示例会报错&＃xff0c;在上述示例中&＃xff0c;Shell将abc.txt看做命令&＃xff0c;而将bbc.txt看做参数。这也说明了通配符的行为&＃xff1a;将满足条件的文件输出为文本&＃xff08;并默认输出到Shell&＃xff09;。
0x06
当我们继续向下挖掘&＃xff0c;我们会想到Shell执行命令的本质&＃xff1a;exec()类系统调用。这一限制如果并非来自于Shell&＃xff08;因为find . -name "*"并不会报错&＃xff09;&＃xff0c;那么就一定来自于系统调用。而一个Shell命令被执行的第一站则是exec()及其六个实际调用&＃xff1a;execl()&＃xff0c;execle()&＃xff0c;execlp()&＃xff0c;execv()&＃xff0c;execvp()&＃xff0c;execve()。
于是我们使用strace工具来检查所有系统调用&＃xff1a;
$ ls
1234.txt
123.txt
$ strace ls *
execve("/usr/bin/ls", ["ls", "1234.txt", "123.txt"], [/* 28 vars */]) &＃61; 0
...
看到这里&＃xff0c;相信读者已经心里有数了&＃xff0c;我们的命令与参数都被作为execve()函数的第二个参数&＃xff0c;以数组形式被传入。考虑到数组默认存储在栈中&＃xff0c;该限制是否来自于Shell对栈空间的限制呢&＃xff1f;
我查阅了Linux的源码&＃xff0c;在fs/exec.c:478中找到了我要的内容&＃xff1a;源码
static int prepare_arg_pages(struct linux_binprm *bprm,struct user_arg_ptr argv, struct user_arg_ptr envp)
{unsigned long limit, ptr_size;bprm->argc &＃61; count(argv, MAX_ARG_STRINGS);if (bprm->argc <0)return bprm->argc;bprm->envc &＃61; count(envp, MAX_ARG_STRINGS);if (bprm->envc <0)return bprm->envc;/** Limit to 1/4 of the max stack size or 3/4 of _STK_LIM* (whichever is smaller) for the argv&＃43;env strings.* This ensures that:* - the remaining binfmt code will not run out of stack space,* - the program will have a reasonable amount of stack left* to work from.*/limit &＃61; _STK_LIM / 4 * 3;limit &＃61; min(limit, bprm->rlim_stack.rlim_cur / 4);/** We&＃39;ve historically supported up to 32 pages (ARG_MAX)* of argument strings even with small stacks*/limit &＃61; max_t(unsigned long, limit, ARG_MAX);/** We must account for the size of all the argv and envp pointers to* the argv and envp strings, since they will also take up space in* the stack. They aren&＃39;t stored until much later when we can&＃39;t* signal to the parent that the child has run out of stack space.* Instead, calculate it here so it&＃39;s possible to fail gracefully.*/ptr_size &＃61; (bprm->argc &＃43; bprm->envc) * sizeof(void *);if (limit <&＃61; ptr_size)return -E2BIG;limit -&＃61; ptr_size;bprm->argmin &＃61; bprm->p - limit;return 0;
}
从完整的注释中我们可以得知&＃xff0c;限制最大参数长度的参数叫做ARG_MAX&＃xff0c;而且其大小为栈的1/4&＃xff08;可能是为了保证参数以外还有多的空间可以存储其他数据&＃xff09;。当然&＃xff0c;如果你是个考古爱好者&＃xff0c;你会发现在2.6版本内核&＃xff08;低于2.6.22&＃xff09;的include/linux/limits.h文件中&＃xff0c;ARG_MAX是一个写死的常量 &＃xff1a;考古链接。
关于ARG_MAX我们可以通过Linux下的getconf命令来获取&＃xff0c;这是一个获取Linux下所有全局变量/常量的命令&＃xff1a;
我们再查询当前配置的栈大小&＃xff1a;
ARG_MAX参数的单位是Byte&＃xff0c;ulimit -s命令的单位是MB&＃xff0c;可以看到当前最大参数数量的确是栈空间的1/4。那如果我们把栈空间增大呢&＃xff1f;
$ ulimit -s 81920
$ ulimit -s
81920
$ getconf ARG_MAX
20971520
可以看到&＃xff0c;允许的最大参数数量立马随着栈空间增大而同步增大。这个时候我们再来删除之前那个大目录&＃xff0c;就不会出现『参数列表过长』的错误提示了。
实际上这一限制在大多数现代操作系统中均存在&＃xff08;例如MacOS、Windows等&＃xff09;&＃xff0c;可参考此处获得更多信息&＃xff1a;ARG_MAX, maximum length of arguments for a new process
京公网安备 11010802041100号