On Fri, Jan 14, 2011 at 11:34:34PM +0530, Umer Q wrote: > > > > What makes you think the data is buffered on disk? > > > > thats what i have learned . as far as we have studied , the file from > pen drive will be first copied to a buffer and we will be viewing and > editing those buffer files , which will be finally put back to pen > drive Where do you see this? We need specifics please. > > And even if it was (it's not) why would you have more permissions to that > > buffer than to the mounted pen drive? > > we are just trying to prove that data can be copied from that > buffer to another location without the knowledge of user, in short , > we steal the data Without root access, I do not think this is possible. With root access, anything is possible, but that's just not anything to study at all, as that's pointless. On Fri, Jan 14, 2011 at 11:29:51PM +0530, Umer Q wrote: > > What "background process"? Who started that process? With what rights? > > How did that process get on the machine in the first place? > > That back ground process which will copy the file to a temp location > without the knowledge of user when he opens it .so there will be 2 > copies. > 1) file the user is viewing > 2) file copied to temp location Where did this background process et started from? Who put it on the computer? If you are running on an "infected" machine, then sure, all bets are off, that's nothing new. > the process will be treated as part of a kernel , installed by me , > with full permission . It will be started with boot up .It will > feature like an inbuilt kernel function Sure, if you want to add something like this to the kernel, to copy data to a "side-channel", then sure, that's possible. But nothing really new, or interesting, or even "realistic" as no one would ever run your kernel without knowing about it, right? I'm guessing this is for a school project? I think you need to go back and get a better definition of it. good luck, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
