开发者

How to access all pipes in the system from Linux kernel space

开发者 https://www.devze.com 2023-03-05 10:49 出处:网络
I want to add a new system call to the Linux kernel that w开发者_高级运维ill show information about all pipes that are created in the system.

I want to add a new system call to the Linux kernel that w开发者_高级运维ill show information about all pipes that are created in the system.

How can I get the inode (or any other related structure that will allow me to access the pipe_inode_info) of every pipe in the pipefs?

I have been looking at struct vfsmount, struct dentry and struct super_block, but I have not found the proper way. Is there any way I could get the file structure of every file in the pipefs?


First I go to /proc directory and the issue:

ls -al */fd |grep pipe

(try taking away the "pipe" above and u will learn more.) and the results are (just a snapshot):

l-wx------ 1 root     root     64 2011-05-14 23:12 17 -> pipe:[39208]
l-wx------ 1 root     root     64 2011-05-14 23:12 2 -> pipe:[16245]
lr-x------ 1 root     root     64 2011-05-14 23:12 4 -> pipe:[23406]
l-wx------ 1 root     root     64 2011-05-14 23:12 8 -> pipe:[23406]
l-wx------ 1 root     root     64 2011-05-14 23:12 17 -> pipe:[39532]
l-wx------ 1 root     root     64 2011-05-14 23:12 2 -> pipe:[16245]
lr-x------ 1 root     root     64 2011-05-14 23:12 4 -> pipe:[23406]
l-wx------ 1 root     root     64 2011-05-14 23:12 8 -> pipe:[23406]
l-wx------ 1 root     root     64 2011-05-14 23:12 1 -> pipe:[16245]
lr-x------ 1 root     root     64 2011-05-14 23:12 16 -> pipe:[40032]
l-wx------ 1 root     root     64 2011-05-14 23:12 17 -> pipe:[40032]
l-wx------ 1 root     root     64 2011-05-14 23:12 2 -> pipe:[16245]
lr-x------ 1 root     root     64 2011-05-14 23:12 4 -> pipe:[23406]
l-wx------ 1 root     root     64 2011-05-14 23:12 8 -> pipe:[23406]
l-wx------ 1 tteikhua tteikhua 64 2011-05-14 23:13 1 -> pipe:[16245]
l-wx------ 1 tteikhua tteikhua 64 2011-05-14 23:13 12 -> pipe:[66674]
lr-x------ 1 tteikhua tteikhua 64 2011-05-14 23:13 13 -> pipe:[66674]
l-wx------ 1 root root 64 2011-05-14 23:30 1 -> pipe:[101794]

And if u want to see the process that created the pipe, just remove the "grep", for example:

Here it shows that the pid=1 is having a pipe fd at 6759:

1/fd:
total 0
dr-x------ 2 root root  0 2011-05-14 23:29 .
dr-xr-xr-x 7 root root  0 2011-05-14 22:59 ..
lrwx------ 1 root root 64 2011-05-14 23:29 0 -> /dev/console (deleted)
lrwx------ 1 root root 64 2011-05-14 23:29 1 -> /dev/console (deleted)
lrwx------ 1 root root 64 2011-05-14 23:29 2 -> /dev/console (deleted)
lr-x------ 1 root root 64 2011-05-14 23:29 3 -> pipe:[6759]

And tracing the above back to fs/pipe.c (linux kernel source that print these):

/*
 * pipefs_dname() is called from d_path().
 */
static char *pipefs_dname(struct dentry *dentry, char *buffer, int buflen)
{
        return dynamic_dname(dentry, buffer, buflen, "pipe:[%lu]",
                                dentry->d_inode->i_ino);
}

static const struct dentry_operations pipefs_dentry_operations = {
        .d_dname        = pipefs_dname,
};

And reading fs/dcache.c:

char *d_path(const struct path *path, char *buf, int buflen)
{
        if (path->dentry->d_op && path->dentry->d_op->d_dname)
                return path->dentry->d_op->d_dname(path->dentry, buf, buflen);

and since d_path() is an exported symbol,

EXPORT_SYMBOL(d_path);

you should be able to call it from anywhere, and derive the information about the path - if it is a pipe then the corresponding pipefs_dname() will be called - it filesystem dependent:

./fs/pipe.c:
    .d_dname    = pipefs_dname,

Read inode.c: init_inode_always() and u can see that i_pipe is set to NULL. It is not null only when the inode is a PIPE.

So u can always loop through all the process and get its opened file descriptor, and it the inode's i_pipe is set to non-NULL, you will know that that value is the inode number of the pipe.

I don't think such codes will exist in the kernel source (so not necessary to hunt for it - I have already tried) as it is much more efficient and safer to do it in userspace (like the "ls -al" command I explained earlier) then inside the kernel - generally the smaller the kernel the lesser security bugs and thus better stability etc.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号