为什么非 root 用户对导出变量调用 getenv 返回 nil

为什么非 root 用户对导出变量调用 getenv 返回 nil

C代码在这里:

#include <stdio.h>
#include <stdlib.h>

int main () {
   printf("PATH : %s\n", getenv("PATH"));
   printf("HOME : %s\n", getenv("HOME"));
   printf("ROOT : %s\n", getenv("ROOT"));
   printf("TMPDIR : %s\n", getenv("TMPDIR"));
   return(0);
}

做完之后:

gcc env.c -o printenv
setcap 'cap_dac_override+eip' printenv
sudo -S su -s $(which bash) steve
export TMDIR=hello
./printenv

我得到这个输出:

PATH : /sbin:/bin:/usr/sbin:/usr/bin
HOME : /home/steve
ROOT : (null)
TMPDIR : (null)

如果我删除设置为“printenv”的 CAP,则输出为:

PATH : /sbin:/bin:/usr/sbin:/usr/bin
HOME : /home/steve
ROOT : (null)
TMPDIR : hello

怎么会这样?

经过一番搜索,我发现了这个:http://polarhome.com/service/man/?qf=secure_getenv&tf=2&of=RedHat&sf=

它提到这可能是由于设置功能时 getenv 变为 secure_getenv 因此所有 getenv() lib 调用都返回 nil,但是在这种情况下,如何PATH打印HOME环境变量?

答案1

好吧,经过一番挖掘,我发现了这背后的原因。 “TMPDIR”是 ld 的特殊变量之一。因此出于安全考虑,当设置 CAP 并且运行用户不是 root 时会忽略。有关更多详细信息,请参阅 ld 的手册页。所以:https://man7.org/linux/man-pages/man8/ld.so.8.html

ENVIRONMENT         top
       Various environment variables influence the operation of the
       dynamic linker.

   Secure-execution mode
       For security reasons, if the dynamic linker determines that a
       binary should be run in secure-execution mode, the effects of
       some environment variables are voided or modified, and
       furthermore those environment variables are stripped from the
       environment, so that the program does not even see the
       definitions.  Some of these environment variables affect the
       operation of the dynamic linker itself, and are described below.
       Other environment variables treated in this way include:
       GCONV_PATH, GETCONF_DIR, HOSTALIASES, LOCALDOMAIN, LOCPATH,
       MALLOC_TRACE, NIS_PATH, NLSPATH, RESOLV_HOST_CONF, RES_OPTIONS,
       TMPDIR, and TZDIR.

       A binary is executed in secure-execution mode if the AT_SECURE
       entry in the auxiliary vector (see getauxval(3)) has a nonzero
       value.  This entry may have a nonzero value for various reasons,
       including:

       *  The process's real and effective user IDs differ, or the real
          and effective group IDs differ.  This typically occurs as a
          result of executing a set-user-ID or set-group-ID program.

       *  A process with a non-root user ID executed a binary that
          conferred capabilities to the process.

       *  A nonzero value may have been set by a Linux Security Module.

相关内容