简体   繁体   English

Linux 文件权限

[英]Linux file permission

There is a process which is running under root user.有一个在 root 用户下运行的进程。

ps aux | grep ProcessX
root     11565  0.0  0.7  82120 22976 ?        Ssl  14:57   0:02 ProcessX

Now ls -l /proc/11565/ (pid ) gives this result.现在ls -l /proc/11565/ (pid ) 给出了这个结果。

total 0
dr-xr-xr-x 2 root root 0 Aug  9 16:06 attr
-rw-r--r-- 1 root root 0 Aug  9 16:06 autogroup
-r-------- 1 root root 0 Aug  9 16:06 auxv
-r--r--r-- 1 root root 0 Aug  9 16:06 cgroup
--w------- 1 root root 0 Aug  9 16:06 clear_refs
-r--r--r-- 1 root root 0 Aug  9 16:06 cmdline
-rw-r--r-- 1 root root 0 Aug  9 16:06 coredump_filter
-r--r--r-- 1 root root 0 Aug  9 16:06 cpuset
lrwxrwxrwx 1 root root 0 Aug  9 16:06 cwd -> /usr/local/bin
-r-------- 1 root root 0 Aug  9 16:06 environ
lrwxrwxrwx 1 root root 0 Aug  9 16:06 exe -> /usr/local/bin/ProcessX
dr-x------ 2 root root 0 Aug  9 16:06 fd
dr-x------ 2 root root 0 Aug  9 16:06 fdinfo
-r-------- 1 root root 0 Aug  9 16:06 io
-rw------- 1 root root 0 Aug  9 16:06 limits
-rw-r--r-- 1 root root 0 Aug  9 16:06 loginuid
-r--r--r-- 1 root root 0 Aug  9 16:06 maps
-rw------- 1 root root 0 Aug  9 16:06 mem
-r--r--r-- 1 root root 0 Aug  9 16:06 mountinfo
-r--r--r-- 1 root root 0 Aug  9 16:06 mounts
-r-------- 1 root root 0 Aug  9 16:06 mountstats
dr-xr-xr-x 6 root root 0 Aug  9 16:06 net
-r--r--r-- 1 root root 0 Aug  9 16:06 numa_maps
-rw-r--r-- 1 root root 0 Aug  9 16:06 oom_adj
-r--r--r-- 1 root root 0 Aug  9 16:06 oom_score
-rw-r--r-- 1 root root 0 Aug  9 16:06 oom_score_adj
-r--r--r-- 1 root root 0 Aug  9 16:06 pagemap
-r--r--r-- 1 root root 0 Aug  9 16:06 personality
lrwxrwxrwx 1 root root 0 Aug  9 16:06 root -> /
-rw-r--r-- 1 root root 0 Aug  9 16:06 sched
-r--r--r-- 1 root root 0 Aug  9 16:06 schedstat
-r--r--r-- 1 root root 0 Aug  9 16:06 sessionid
-r--r--r-- 1 root root 0 Aug  9 16:06 smaps
-r--r--r-- 1 root root 0 Aug  9 16:06 stack
-r--r--r-- 1 root root 0 Aug  9 16:06 stat
-r--r--r-- 1 root root 0 Aug  9 16:06 statm
-r--r--r-- 1 root root 0 Aug  9 16:06 status
-r--r--r-- 1 root root 0 Aug  9 16:06 syscall
dr-xr-xr-x 6 root root 0 Aug  9 16:06 task
-r--r--r-- 1 root root 0 Aug  9 16:06 wchan

Now the file permission for both status and maps are same ( -r--r--r-- ).现在状态和地图的文件权限相同( -r--r--r-- )。 But when I issue cat /proc/11565/maps with a non privileged (not root) user, it gives me a permission denied.但是当我使用非特权(不是 root)用户发出cat /proc/11565/maps时,它给了我一个被拒绝的权限。 But for cat /proc/11565/status , it outputs as expected.但是对于cat /proc/11565/status ,它会按预期输出。

Is there something I am missing here?有什么我在这里想念的吗?

It's because the file permissions are not the only protection you're encountering.这是因为文件权限不是您遇到的唯一保护。

Those aren't just regular text files on a file system, procfs is a window into process internals and you have to get past both the file permissions plus whatever other protections are in place.这些不仅仅是文件系统上的常规文本文件, procfs是进入进程内部的窗口,您必须通过文件权限以及任何其他到位的保护。

The maps show potentially dangerous information about memory usage and where executable code is located within the process space.这些映射显示了有关内存使用情况以及可执行代码在进程空间中的位置的潜在危险信息。 If you look into ASLR, you'll see this was a method of preventing potential attackers from knowing where code was loaded and it wouldn't make sense to reveal it in a world-readable entry in procfs .如果您查看 ASLR,您会发现这是一种防止潜在攻击者知道代码加载位置的方法,并且在procfs中的世界可读条目中显示它是没有意义的。

This protection was added way back in 2007 :这种保护是在 2007年添加的:

This change implements a check using "ptrace_may_attach" before allowing access to read the maps contents.此更改在允许访问读取地图内容之前使用“ptrace_may_attach”实施检查。 To control this protection, the new knob /proc/sys/kernel/maps_protect has been added, with corresponding updates to the procfs documentation.为了控制这种保护,添加了新的旋钮 /proc/sys/kernel/maps_protect,并对 procfs 文档进行了相应的更新。

Within ptrace_may_attach() (actually within one of the functions it calls) lies the following code:ptrace_may_attach() (实际上在它调用的函数之一中)包含以下代码:

if (((current->uid != task->euid) ||
     (current->uid != task->suid) ||
     (current->uid != task->uid) ||
     (current->gid != task->egid) ||
     (current->gid != task->sgid) ||
     (current->gid != task->gid))     && !capable(CAP_SYS_PTRACE))
   return -EPERM;

so that, unless you have the same real user/group ID, saved user/group ID and effective user/group ID (ie, no sneaky setuid stuff) and they're the same as the user/group ID that owns the process, you're not allowed to see inside that "file" (unless your process has the CAP_SYS_PTRACE capability of course).因此,除非您具有相同的真实用户/组 ID、保存的用户/组 ID 和有效用户/组 ID(即,没有偷偷摸摸的setuid内容)并且它们与拥有该进程的用户/组 ID 相同,您不能看到该“文件”的内部(除非您的进程当然具有CAP_SYS_PTRACE功能)。

The process uid must match the smaps uid, and the process gid must match the smaps gid.进程 uid 必须匹配 smaps uid,进程 gid 必须匹配 smaps gid。

$ ls -l /proc/15889/smaps /proc/16139/smaps
-r--r--r--. 1 oracle dba      0 Feb 10 16:42 /proc/15889/smaps
-r--r--r--. 1 oracle asmadmin 0 Feb 10 16:42 /proc/16139/smaps
$ wc /proc/15889/smaps /proc/16139/smaps
6851 23498 224275 /proc/15889/smaps
wc: /proc/16139/smaps: Permission denied
6851 23498 224275 total
$ id
uid=400(oracle) gid=400(dba) groups=400(dba),522(asmadmin),etc.

Same for environ, io, and all memory maps.对于环境、io 和所有内存映射也是如此。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM