CentOS6.x 下 /etc/security/limits.conf 被改错的故障经历

Intro

我司本小厂,每个员工都是身兼数职,所以开发人员直接登录线上服务器改东西是常态。有些开发人员,自持水平较高(的确水平也是较高,但缺乏对系统的敬畏),所以总是越俎代庖,改一些本身应该是线上运维人员改动的配置。本文提到的 /etc/security/limits.conf 两次改错导致的事故,皆是因为于此。

In details

The first time

第一次是在 /etc/security/limits.conf 中加了两句:

1
2
*	soft	nofile	unlimited
* hard nofile unlimited

结果就是:
所有用户无法登录。一登录,马上被踢出来。

最后解决方法:
单用户进系统把文件 /etc/security/limits.conf 改回来。

原因:
配置文件 /etc/security/limits.conf 中 nofile 的参数,只支持数字,”unlimited” 显然系统不认。

The second time

第二次也是在 /etc/security/limits.conf 中加了两句:

1
2
root	soft	nofile	2000000
root hard nofile 2000000

结果是:

  • root 用户一登录,就被踢
  • 普通用户可登录,但 sudo su - 一切成 root 马上会被踢(但普通用户只支持 sudo su -

解决方法:
像前面文章 一次本地提权的实战演练 有提到的:

  1. 普通用户登录
  2. 用 DirtyCow(脏牛)本地提权
  3. 然后把 /etc/security/limits.conf 改回去。

原因:

  1. 配置文件 /etc/security/limits.conf 中 nofile 的参数,其最大值不能大于 kernel 参数 NR_OPEN 的限制
  2. 而 kernel 2.6.32 里,NR_OPEN 的值缺省为 1024*1024=1048576
  3. 这里的 2000000>1048576,所以出错被踢

稍稍延展一下,如果我一定要将 nofile 参数设置为 2000000呢?
其实这也有办法,提高 kernel 里 NR_OPEN 的值即可,具体方法是:

1
2
3
[[ ! -e /etc/sysctl.d ]] && mkdir /etc/sysctl.d;
echo "fs.nr_open = 2000000" > /etc/sysctl.d/nr_open.conf;
sysctl -w fs.nr_open=2000000;

总结

总而言之,言而总之:Linux 下配置文件 /etc/security/limits.conf 文件不要随意改动。我其实还是倾向于在启动服务的启动脚本里手工用 ulimit 命令来设置相关参数而不要直接在 /etc/security/limits.conf 文件里改。