/etc/profile.d 用于模块化加载系统级环境配置脚本，要求目录权限755、脚本可读（如644），按字母序source执行，但不提权，仅以当前用户身份运行配置命令。
/etc/profile.d 是一个用于模块化管理全局环境配置的目录，它本身不直接控制“初始化权限”，而是承担系统级环境变量与行为设置的分发职责。它的作用机制和实际权限影响，关键在于执行时机、文件所有权与读取权限三者配合。
/etc/profile.d 的加载逻辑
该目录下所有以 .sh 结尾的脚本，会在用户登录时由 /etc/profile 自动 sourced（即执行）。典型加载代码如下：
- for i in /etc/profile.d/*.sh; do [ -r "$i" ] && . "$i"; done
- 这意味着只要脚本存在、可读（-r），就会被加载执行
- 执行顺序按字母顺序排列（如 00-java.sh 先于 10-hadoop.sh）
初始化时的实际权限要求
脚本能否生效，取决于两个基础权限条件：
- 目录 /etc/profile.d 必须对所有用户可读（通常权限为 755，属主 root:root）
- 单个 .sh 文件必须至少具备读权限（推荐 644；不可执行也可加载，因为是 source 而非 exec）
- 文件内容若包含需要特权的操作（如修改 PATH、设置 umask、定义全局 alias），这些操作在用户 shell 启动时以当前用户身份运行，不提升权限
为什么不能靠它提权？
/etc/profile.d 脚本运行在用户 shell 环境中，不具备 root 权限：
- 即使脚本由 root 创建，source 执行时仍受限于当前登录用户的 UID/GID
- 无法绕过 sudo 或 su 直接执行需要 root 权限的命令（如 systemctl、mount）
- 常见误用：试图在 profile.d 脚本里写 sudo 命令——这会失败或触发密码提示，破坏自动登录流程
安全建议与典型实践
合理使用 /etc/profile.d 需注意以下几点：
- 只放纯配置类脚本（export 变量、alias、umask、PATH 追加等）
- 避免硬编码敏感路径或密钥；如需动态值，应通过 /etc/environment 或专用服务管理
- 新增脚本后，用 source /etc/profile.d/xxx.sh 测试语法，再用新终端验证效果
- 若需限制某脚本仅对特定用户生效，应在脚本内添加判断逻辑（如 [ "$USER" = "admin" ]）
