背景

使用的是公有云，最近要对k8s版本进行升级，在升级之后发发现从我们的web terminal 进入到容器，
拥有sudo权限的用户无法进行sudo命令,即使使用root通过docker exec 进入到容器，依旧无法sudo

sudo: pam_open_session: Permission deniedsudo: policy plugin failed session initialization

定位

进入到容器中我们查看ulimit -a 如下

core file size          (blocks, -c) 5242880data seg size           (kbytes, -d) unlimitedscheduling priority             (-e) 0file size               (blocks, -f) unlimitedpending signals                 (-i) 3806max locked memory       (kbytes, -l) 82000max memory size         (kbytes, -m) unlimitedopen files                      (-n) 1048576pipe size            (512 bytes, -p) 8POSIX message queues     (bytes, -q) 819200real-time priority              (-r) 0stack size              (kbytes, -s) 8192cpu time               (seconds, -t) unlimitedmax user processes              (-u) unlimitedvirtual memory          (kbytes, -v) unlimitedfile locks                      (-x) unlimited

我们基础镜像里面的/etc/security/limits.conf配置如下

* soft core unlimited* hard core unlimited* soft nofile 1048576* hard nofile 1048576root soft nofile 1048576root hard nofile 1048576* soft nproc 102400* hard nproc 102400

可见我们在/etc/security/limits.conf配置文件中的配置并未生效，
查看psp，公有云也未做psp相关的初始配置，通过docker inspect查看，并没有相关ulimit设置，
最终查看systemd发现docker.service配置多了一行

LimitCORE=5368709120

这里的值是单位是字节 和 内部ulimit看到的有所差异，ulimit看到的是block数
systemd 中有关limit的配置对照表如下

指令等价的ulimit 命令单位LimitCPUulimit -t秒LimitFSIZE=ulimit -f字节LimitDATA=ulimit -d字节LimitSTACK=ulimit -s字节LimitCORE=ulimit -c字节LimitRSS=ulimit -m字节LimitNOFILE=ulimit -n文件描述符的数量LimitAS=ulimit -v字节LimitNPROC=ulimit -u进程的数量LimitMEMLOCK=ulimit -l字节LimitLOCKS=ulimit -x锁的数量LimitSIGPENDING=ulimit -i信号队列的长度(排队的信号数量)LimitMSGQUEUE=ulimit -q字节LimitNICE=ulimit -e谦让度LimitRTPRIO=ulimit -r实时优先级LimitRTTIME=不存在微秒

由此可见最终生效的是systemd下core file size 的值，那为什么会出现上面的报错呢？

pam_limits.so

查看linux sudo pam 配置如下

#%PAM-1.0auth       include      system-authaccount    include      system-authpassword   include      system-authsession    optional     pam_keyinit.so revokesession    required     pam_limits.so

可以看到sudo加载了pam_limits.so模块，而limits.conf 文件实际是 Linux PAM(插入式认证模块，Pluggable Authentication Modules)中 pam_limits.so 的配置文件

有关pam类型如下

由此可知当我们执行sudo时触发了pam_limits.so模块的某些限制，导致执行失败,

实际上pam_limits.so的实现主要包括以下步骤：

• 解析配置文件 /etc/security/limits.conf及/etc/security/limits.d下的*.conf文件
• setup_limits调用setrlimits生效配置

setrlimit和getrlimit系统调用

pam_limits.so进行了setrlimit和getrlimit系统调用,setrlimit和getrlimit的定义如下

int getrlimit(int resource, struct rlimit *rlim);int setrlimit(int resource, const struct rlimit *rlim);

在linux系统中，Resouce limit指在一个进程的执行过程中，它所能得到的资源的限制，比如进程的core file的最大值，虚拟内存的最大值等。

Resouce limit的大小可以直接影响进程的执行状况。其有两个最重要的概念：soft limit 和 hard limit。

soft limit和hard limit概念如下：

• soft limit是指内核所能支持的资源上限。对于RLIMIT_COREsoft limit最大能是unlimited。
• hard limit在资源中只是作为soft limit的上限，当你设置hard limit后，你以后设置的soft limit只能小于hard limit。

struct rlimit {　　rlim_t rlim_cur;　　//soft limit　　rlim_t rlim_max;　　//hard limit};

根据man文档在进行setrlimit系统调用时操作系统会检查新的值是否超过当前hard limit,对于root没有这种限制

返回错误码如下

EFAULT：rlim指针指向的空间不可访问
EINVAL：参数无效
EPERM：增加资源限制值时，权能不允许
EPERM对应的返回为：Operation not permitted
这和我们手动执行ulimit的返回一致

容器内的root如何突破限制

在docker没有添加 CAP_SYS_RESOURCE 时，才可以突破内核上限，所以docker内部的root并不是真正的root

docker run --cap-add CAP_SYS_RESOURCE # 或者docker run --privileged

这样容器内部的root用户就可以突破该ulimit限制

容器ulimit设置原则

• dockerd和容器都设置为unlimited
• 容器设置的limit比宿主机小
• 为容器添加CAP_SYS_RESOURCE capability
• 容器开启privileged(不推荐)
• 不设置，以dockerd为准

扫描关注我:

​