linux内核代码在哪个文件,Linux内核中的代码在哪里打开(“/ proc / self / fd / NUM”)？...

我一直认为开放(/ proc / self / fd / NUM,flags)相当于dup(NUM),但显然情况并非如此！例如,如果您复制文件描述符,然后将新fd设置为非阻塞,这也会影响原始文件描述符(因为非阻塞状态是文件描述的属性,并且两个文件描述符都指向相同的文件描述).但是,如果您打开/ proc / self / fd / NUM,那么您似乎获得了一个新的独立文件描述,并且可以独立设置旧的和新的fds的非阻塞状态.您甚至可以使用它来获取引用相同匿名管道的两个文件描述,否则这是不可能的(example).另一方面,虽然您可以复制套接字fd,但如果NUM引用套接字,则open(“/ proc / self / fd / NUM”,flags)将失败.

现在我希望能够看到这对于其他类型的特殊文件是如何工作的,并回答诸如“以这种方式重新打开文件时进行了哪些权限检查？”这样的问题,所以我试图找到代码Linux实际上实现了这条路径,但是当我开始阅读fs / proc / fd.c时,我很快迷失在一个错误的操作结构迷宫中,各种各样.

所以我的问题是：任何人都可以解释开放后的代码路径(“/ proc / self / fd / NUM”,flags)吗？具体来说,NUM表示一个管道,我们正在讨论最新的内核版本.

解决方法:

评论建议看看proc_fd_link,这是一个好主意.如果您无法遵循代码的实现方式,那么您可以使用systemtap来帮助自己.这是一个神奇的脚本：

probe kernel.function("proc_fd_link") {

print_backtrace();

}

从fd /下打开文件时运行它给出：

0xffffffffbb2cad70 : proc_fd_link+0x0/0xd0 [kernel]

0xffffffffbb2c4c3b : proc_pid_get_link+0x6b/0x90 [kernel] (inexact)

0xffffffffbb36341a : security_inode_follow_link+0x4a/0x70 [kernel] (inexact)

0xffffffffbb25bf13 : trailing_symlink+0x1e3/0x220 [kernel] (inexact)

0xffffffffbb25f559 : path_openat+0xe9/0x1380 [kernel] (inexact)

0xffffffffbb261af1 : do_filp_open+0x91/0x100 [kernel] (inexact)

0xffffffffbb26fd8f : __alloc_fd+0x3f/0x170 [kernel] (inexact)

0xffffffffbb24f280 : do_sys_open+0x130/0x220 [kernel] (inexact)

0xffffffffbb24f38e : sys_open+0x1e/0x20 [kernel] (inexact)

0xffffffffbb003c57 : do_syscall_64+0x67/0x160 [kernel] (inexact)

0xffffffffbb8039e1 : return_from_SYSCALL_64+0x0/0x6a [kernel] (inexact)

在proc_pid_get_link中,我们看到：

/* Are we allowed to snoop on the tasks file descriptors? */

if (!proc_fd_access_allowed(inode))

goto out;

aaaand

/* permission checks */

static int proc_fd_access_allowed(struct inode *inode)

{

struct task_struct *task;

int allowed = 0;

/* Allow access to a task's file descriptors if it is us or we

* may use ptrace attach to the process and find out that

* information.

*/

task = get_proc_task(inode);

if (task) {

allowed = ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS);

put_task_struct(task);

}

return allowed;

}

显然,你需要相同的烫发,就好像你附加了ptrace一样.

最后,为什么打开套接字会失败？ strace显示ENXIO被退回.快速git grep ENXIO fs / * .c显示：

static int no_open(struct inode *inode, struct file *file)

{

return -ENXIO;

}

使用no_open检查代码的结果是留给读者的练习.另请注意,systemtap可用于类似printf的调试,无需修改源代码.它也可以从函数“返回”并报告错误代码.

标签：linux,linux-kernel

来源： https://codeday.me/bug/20190627/1306784.html