lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <200501251619.j0PGJqvx013025@turing-police.cc.vt.edu>
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: Mirroring procfs. 

On Tue, 25 Jan 2005 08:58:39 GMT, preeth k said:

> I work on Redhat Linux and we want to know if there is any method to mirror
> the '/proc' filesystem on one machine-A to another machine-B so as to monitor
> all the events occuring in A using machine-B

The problem is that even if you *could* mirror /proc in any sensible way,
that would not actually monitor "all the events".  If you look closely at
the source code for the 'procfs' file system (see the code in fs/proc/*.c),
you'd realize that /proc entries are created *on the fly*.  There's not really
anything *in* that file system - it all gets created "on the fly" as you
reference it.  Sure, /proc/$$/cwd *looks* like a symlink to your current working
directory, but look how it's actually implemented (looking at a 2.6.11-rc2-mm1
kernel here, your code may differ):

static int proc_cwd_link(struct inode *inode, struct dentry **dentry, struct vfsmount **mnt)
{
        struct fs_struct *fs;
        int result = -ENOENT;
        task_lock(proc_task(inode));
        fs = proc_task(inode)->fs;
        if(fs)
                atomic_inc(&fs->count);
        task_unlock(proc_task(inode));
        if (fs) {
                read_lock(&fs->lock);
                *mnt = mntget(fs->pwdmnt);
                *dentry = dget(fs->pwd);
                read_unlock(&fs->lock);
                result = 0;
                put_fs_struct(fs);
        }
        return result;
}

The magic here is "*dentry = dget(fs->pwd);" - basically, they just create a clone
of a reference to the process's working directory and return it.

Similarly, the list of directories /proc/NNN for each process ID NNN is generated
on the fly by walking the process table.  So if a process fork()s to create a new
PID, it does *NOT* create a /proc entry *unless somebody actually looks for it*.
If you fork and create process 994, and then it exits before anybody looks in /proc
for it, /proc/994 *never actually happens*.

What you *really* need to mirror to machine-b is enough information of the kernel's
internal state (fork/exec/open/and all the rest), so that your monitor on B is able
to track what's going on...

What "events" were you hoping to monitor, and why?  Understanding that would
help a lot in pointing you in a useful direction....

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050125/1bb86a7a/attachment.bin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ