Well kprobe is: 1. meant to instrument debugging while developing 2. Is configured with kernel configuration parameters which you can not guarantee to be configured on deployment site. 3. slower as it works with debugger break point instruction and single stepping mode. 4. probing into an instruction and altering behavior might not scale across kernel version and interface changes. But yes, you can technically capture any kernel instruction's virtual address and probe into it. Building solution on top of such instrumentation -- HACK!! :) Did you try looking for LSM as well? -Rajat On Thu, Dec 29, 2011 at 3:53 PM, Gaurav Saxena <grvsaxena419@xxxxxxxxx> wrote: > On 12/29/11, Rajat Sharma <fs.rajat@xxxxxxxxx> wrote: >> I would suggest that you go through the stackable FS documentation >> maintained with wrapfs website: >> >> http://wrapfs.filesystems.org/docs/linux-stacking/index.html >> >> there is no replacement of fops, that again I would categorize as pure >> "HACK". Here you build a stack of FS on top of existing one. so stack >> fs appears as regular FS to VFS layer and as VFS to lower FS, it just >> fits in between VFS and lower FS. To do it tranparent to applications >> you need to mount wrapfs on the same mount point as lower fs so that >> you hide direct exposure to lower FS and application can still assume >> same file paths as lower FS. > I am going through their documentation. I see this means I could > intercept in between for filesystems on which I mount this file system > and thus could do what I want to do. I can skip entire system calls I > suppose. Also I am thinking of KProbes is it possible to skip system > call using kprobes ? > Thanks a lot for your help. >> >> Thanks, >> Rajat >> >> On Thu, Dec 29, 2011 at 12:12 PM, Gaurav Saxena <grvsaxena419@xxxxxxxxx> >> wrote: >>> Hello Rajat, Thanks for your reply. >>> >>> On 12/28/11, Rajat Sharma <fs.rajat@xxxxxxxxx> wrote: >>>> wrapfs needs the underlying filesystem to be already mounted and then >>>> it attaches itself on top of this mount point. >>> Ok That means it will replace the specific file system operations with >>> its own operations ? And then call the specific operations from >>> itself? Doesn't it then requires a different operation for each file >>> system ? >>>>Thats the whole idea of >>>> stacking one to one VFS objects from wrapfs to underlying FS objects. >>>> So it assumes that / to be already mounted. And you would want to >>>> attach to a route volume as soon as possible, so entering wrapfs mount >>>> entry in /etc/fstab just after / entry should be good enough. >>> Do I need volumes for using wrapfs ? Or simple partitioning would >>> suffice ? It sounds quite good I would look at this. >>>> >>>> Thanks, >>>> Rajat >>>> >>>> On Wed, Dec 28, 2011 at 11:29 AM, Gaurav Saxena <grvsaxena419@xxxxxxxxx> >>>> wrote: >>>>> Hello Rajat Thanks for your reply. >>>>> >>>>> On Mon, Dec 26, 2011 at 11:23 AM, Rajat Sharma <fs.rajat@xxxxxxxxx> >>>>> wrote: >>>>>> Hi Gaurav, >>>>>> >>>>>> I would suggest to take a wrapfs source (a null stackable file-system) >>>>>> and customize it for your need. Well Erez (wrapfs author) puts his >>>>>> continuous efforts in stabilizing wrapfs and porting to new kernels >>>>>> and he is approachable too. In-fact he has acknowledged on of my patch >>>>>> and merged it into wrapfs tree. >>>>> Is there a way to mount "/" on such file system ? Like I want to >>>>> monitor / for changes like unlink or modified write. Would I be able >>>>> to see such changes using wrapfs. As by default on the systems "/" >>>>> would be mounted as ext4 filesystem. >>>>>> >>>>>> Agreed that you can do stuffs like patching system call table but I >>>>>> (and most of us here) would categorize that as pure hack, as there >>>>>> exist no framework provided by kernel to do that. Also any approach >>>>>> you take to patch system call table won't be stable. >>>>> Yes I agree with you I want to do this using a method which is not a >>>>> hack, so that the support remains with all the versions of kernel >>>>> rather than a trick that works in a limited way. >>>>>> >>>>>> Thanks, >>>>>> Rajat >>>>>> >>>>>> On Sat, Dec 24, 2011 at 2:39 PM, Gaurav Saxena <grvsaxena419@xxxxxxxxx> >>>>>> wrote: >>>>>>> Hello all, >>>>>>> >>>>>>> I am writing an application which would create a backup for the system >>>>>>> so that it could be restored as it is. For example I create a backup >>>>>>> using my application. I just do nothing at time of backup so it would >>>>>>> be fast. Now whenever I see any deletion I would save that file so >>>>>>> that I could restore it. Also I would like to see for >>>>>>> modification/rename. I cannot do this using inotify as I would be >>>>>>> notified after actual deletion/write. I don't want to use SELinux >>>>>>> because I want to implement this on existing installed system. I was >>>>>>> earlier thinking of replacing system calls for open/unlink with my >>>>>>> custom calls which will call my functions before actual work and then >>>>>>> I would decide what to do I would also want to reject unlink request >>>>>>> for some of the files. But as I now know that its not working in >>>>>>> linux>3.0 . I had also seen dazuko which is not supporting linux>3.0 >>>>>>> yet. Also there used to be a redirfs which used to work earlier but >>>>>>> the latest kernel is not supported yet. I think a method could be to >>>>>>> replace unlink in syscall table with my unlink function but I don't >>>>>>> find any good method of doing that, as syscall table is no longer >>>>>>> exported. I would like to implement this in a kernel module instead of >>>>>>> modifying kernel code itself. Please suggest some method of doing >>>>>>> that. >>>>>>> Thanks to you all for your help. >>>>>>> >>>>>>> -- >>>>>>> Thanks and Regards , >>>>>>> Gaurav >>>>>>> -- >>>>>>> To unsubscribe from this list: send the line "unsubscribe >>>>>>> linux-fsdevel" >>>>>>> in >>>>>>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>>> >>>>> >>>>> >>>>> -- >>>>> Thanks and Regards , >>>>> Gaurav >>>> >>> >>> >>> -- >>> Thanks and Regards , >>> Gaurav >> > > > -- > Thanks and Regards , > Gaurav -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
