How to Replace File Operations in File System?

Hi list,

I am a newbie in linux kernel programming. Recently I got stuck in a problem when doing
practice in file system programming. I hope this list is the right place I can turn to.

I want to replace some file operations of files in a certain directory,so that data can be
decrypted/encrypted through read/write system call. So I:

#1: Find the directory inode, save its original inode operation table,then replace
the table:

kern_path(pathname, LOOKUP_FOLLOW, &target_dir_path); lower_iops = target_dir_path.dentry->d_inode->i_op; target_dir_path.dentry->d_inode->i_op = &my_iops;

#2: In my_iops, I mainly changed ".lookup" function like this to achive my goal ??
replace the file operation table of all files in the directory.

static struct dentry *my_inode_lookup(struct inode *dir, struct dentry *dentry,
struct nameidata *nd)
{
struct dentry *ret_dentry;

ret_dentry = lower_iops->lookup(dir,dentry,nd);
if (!ret_dentry)
goto out;
ret_dentry->d_inode->i_fop = &my_fops;
out:
return ret_dentry;
}

Things turns out that replacement of inode operation table of directory is successful
but the changes in file operations are not functional: system works as it used to,
totally ignore my_fops!

I have no idea how to fix it. Can anybody help?
Thanks for your attention!
Regards

Freeman Zhang

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Hi,

Quoted 11 lines · freeman

Hi list,

I am a newbie in linux kernel programming. Recently I got stuck in a problem when doing
practice in file system programming. I hope this list is the right place I can turn to.

I want to replace some file operations of files in a certain directory,so that data can be
decrypted/encrypted through read/write system call. So I:

Quoted 8 lines

#1: Find the directory inode, save its original inode operation table,then replace
the table:

kern_path(pathname, LOOKUP_FOLLOW, &target_dir_path); lower_iops = target_dir_path.dentry->d_inode->i_op; target_dir_path.dentry->d_inode->i_op = &my_iops;

I assume that you are writing your own stackable filesystem. Take a look at WRAPFS[1] and ecryptfs[2]. As a matter of fact, ecryptfs does what you are expecting.

To do this, you need to set your superblock operations for the lower directory inode so the VFS use your filesystem instead of the original filesystem.
Important steps to look are:
1. get lower superblock from the lower directory inode
2. assign this superblock as an overlay for your own superblock.
3. Set your own superblock operations for the new superblock
4. get a root inode for your superblock using the lower directory inode
5. While you are getting the inode, you can set the file operations on this inode which will help you achieve your case.

The point to note that you need to interpose the inodes with VFS so that everything would be routed to your filesystem.

--
Abhijit.
[1]http://wrapfs.filesystems.org/
[2]http://ecryptfs.org/

Quoted 28 lines

#2: In my_iops, I mainly changed ".lookup" function like this to achive my goal ??
replace the file operation table of all files in the directory.

static struct dentry *my_inode_lookup(struct inode *dir, struct dentry *dentry,
struct nameidata *nd)
{
struct dentry *ret_dentry;

ret_dentry = lower_iops->lookup(dir,dentry,nd);
if (!ret_dentry)
goto out;
ret_dentry->d_inode->i_fop = &my_fops;
out:
return ret_dentry;
}

Things turns out that replacement of inode operation table of directory is successful
but the changes in file operations are not functional: system works as it used to,
totally ignore my_fops!

I have no idea how to fix it. Can anybody help?
Thanks for your attention!
Regards

Quoted 8 lines

Freeman Zhang

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Hi Rishi,

Thanks for your reply!

I'm sorry that the description of the problem was not clear.

I am writing a module(not a filesystem) to replace some operation pointers of Ext4.
Just now, I try to print the dentry->name as you said. It seems that I'm modifying the right files.

I'm wonderring if my idea is bad:
I changed operations of a file both in ->create and ->lookup in inode operations of direcotry. And test the module like this:

echo hello > hello (for dir_inode->create and f->write)
cat hello (for f->read)

Will the file operations be changed back?
Or what I modified is some copies of real objects because of the complex caching mechanism?

Regards

Freeman Zhang

Hi

The operations will not change back until your object gets destroyed, whatever be the type of the object.

Caching will not cause any issue here.

Maybe if you can send the code we can have a look at it.

Signature · 2 lines

Regards,
Rishi Agrawal

Good that you solved it your self, still if you can send me the idea on which you are working - I may also learn something.

Quoted 3 lines · On Tue, Feb 18, 2014 at 10:04 AM, freeman <[email protected]…

Hi

The operations will not change back until your object gets

destroyed,
> whatever be the type of the object.
>
> Caching will not cause any issue here.
>
> Maybe if you can send the code we can have a look at it. >
>
> --
> Regards,
> Rishi Agrawal
Hi Rishi,

It's very nice of you willing to help check my code! I'm now very excited ? problem solved!

I spent half a day beautifying my code yesterday (so that it won't annoy
you
that much), and find there is a problem:

Every time there is a read/write system call, I saved the lower file ops
and
address space ops. In their replacement(upper operations), I invoked lower ones.
There's a possibility that it might saved the upper operations as lower
ones if I
open them twice in a short time. At this point, upper operation invoke itself!
So I check the operations before truly save and replace them and, it works!

Thanks to you and all the amazing people in this amazing list that helped me,
now I get both wrapfs and my own non-filesystem module functional for my
future work on transparent encryption, and most importantly, I've learned and
enjoyed a lot!

Regards
Freeman Zhang

Signature · 2 lines

Regards,
Rishi Agrawal

Hi Rishi,

With pleasure!
You can check it on https://github.com/freemandealer/droidcry
on your convenience.

2014-02-19 23:17, Rishi Agrawal :

Good that you solved it your self, still if you can send me the idea on which you are working - I may also learn something.

Quoted 41 lines · freeman

Quoted 6 lines

Hi

The operations will not change back until your object gets destroyed, whatever be the type of the object.

Quoted 8 lines

Caching will not cause any issue here.

Maybe if you can send the code we can have a look at it.

--
Regards,
Rishi Agrawal

Hi Rishi,

It's very nice of you willing to help check my code! I'm now very excited ? problem solved!

I spent half a day beautifying my code yesterday (so that it won't annoy you
that much), and find there is a problem:

Every time there is a read/write system call, I saved the lower file ops and
address space ops. In their replacement(upper operations), I invoked lower ones.
There's a possibility that it might saved the upper operations as lower ones if I
open them twice in a short time. At this point, upper operation invoke itself!
So I check the operations before truly save and replace them and, it works!

Thanks to you and all the amazing people in this amazing list that helped me,
now I get both wrapfs and my own non-filesystem module functional for my future work on transparent encryption, and most importantly, I've learned and
enjoyed a lot!

Quoted 3 lines

Regards
Freeman Zhang

--
Regards,
Rishi Agrawal

Regards
Freeman Zhang

Hi,

I went through your readme. Some questions.

1. How are you encrypting the files? Is it done by the encryptfs or you are doing it in your module.

2. How can the user selectively encrypt the files in the system.

Signature · 2 lines

Regards,
Rishi Agrawal

2014-02-20 15:31, Rishi Agrawal :

Hi,

I went through your readme. Some questions.

1. How are you encrypting the files? Is it done by the encryptfs or you
are doing it in your module.

2. How can the user selectively encrypt the files in the system.

--
Regards,
Rishi Agrawal

Hi Rishi,

Sorry about the fuzziness.

#1 I plan to do the encryption in my module, but encrypting functions aren't added to it yet. As I mentioned in readme, module now just simply pass-through operations to the original file system.

#2 It seems that the user cannot select specific file to encrypt inside one directory :-( . However he may specify a directory then we can encrypt all the file inside it. Namely, the granularity is directory, not file. Besides, subdirectory is not supported at present.

Regards
Freeman

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

On Thu, Feb 20, 2014 at 2:27 PM, freeman <[email protected] <mailto:[email protected]>> wrote:

    2014-02-20 15:31, Rishi Agrawal :

Quoted 7 lines

Hi,

I went through your readme. Some questions.

1. How are you encrypting the files? Is it done by the encryptfs or you are doing it in your module.

Quoted 6 lines

2. How can the user selectively encrypt the files in the system.

--
Regards,
Rishi Agrawal

Hi Rishi,

Sorry about the fuzziness.

#1 I plan to do the encryption in my module, but encrypting functions aren't added to it yet. As I mentioned in readme, module now just simply pass-through operations to the original file system.

#2 It seems that the user cannot select specific file to encrypt inside one directory :-( . However he may specify a directory then we can encrypt all the file inside it. Namely, the granularity is directory, not file. Besides, subdirectory is not supported at present.

Why does it even matter - inode vs directory? Is it because you store the encryption metadata in the dirent and not the inode?

Regards
Freeman

Signature · 4 lines

Regards,
Sandeep.

"To learn is to change. Education is a process that changes the learner."

2014-02-2017:10, SandeepKsinha :

Quoted 26 lines · freeman

2014-02-20 15:31, Rishi Agrawal :

Hi,

I went through your readme. Some questions.

1. How are you encrypting the files? Is it done by the encryptfs or
you are doing it in your module.

2. How can the user selectively encrypt the files in the system.

--
Regards,
Rishi Agrawal

Hi Rishi,

Sorry about the fuzziness.

#1 I plan to do the encryption in my module, but encrypting functions aren't added to it yet. As I mentioned in readme, module now just simply pass-through operations to the original file system.

Quoted 7 lines

#2 It seems that the user cannot select specific file to encrypt inside one directory :-( . However he may specify a directory then we can encrypt all the file inside it. Namely, the granularity is directory, not file. Besides, subdirectory is not supported at present.

Why does it even matter - inode vs directory? Is it because you store
the encryption metadata in the dirent and not the inode?

Quoted 5 lines

Regards
Freeman

--
Regards,
Sandeep.

?To learn is to change. Education is a process that changes the learner.?

Hi Sandeep,

Actually I haven't got that far...
However as I planed it, I don't want involve the user too much? just to keep simple. I plan to build a safe box, and people throw personal things into it. That's all.
I want to use it with Android devices. Will complex implementation build barrier for ebedded system?
Any suggestions?

Regards
Freeman Zhang

However as I planed it, I don't want involve the user too much- just to keep simple. I plan to build a safe box, and people throw personal things into it. That's all.

The first question is - what are you trying to protect against? The answer to that will influence your design.

As Bruce Schneier said in the intro to Applied Cryptography:

There are two kinds of cryptography in this world: cryptography that will stop your kid sister from reading your files, and cryptography that will stop major governments from reading your files. This book is about the latter.

It's one thing to write a silly kernel module that will rot13 your files. It's totally another to design a complete system that works.

Do you need to worry about a directory being open for access to encrypted files, and another rogue process on the system simply going and reading the files and the crypto doesn't matter? (This is an issue for cryptLUKS, for instance - it defends against somebody stealing a powered-off laptop, but not against processes that get access to a running system. You may wish to think for a bit about what security is provided by a system that is suspended, rather than powered off - particularly in the case of cold-boot attacks....)

Do you need to worry about somebody replacing the binary that prompts the user for the passphrase before loading it into the kernel, with a version that saves the passphrase for later, after the device has been "recovered" via theft or similar? (And yes, this *has* been used before, see 'FBI v Scarfo', where they installed a keylogger to snag a PGP passphrase:

https://epic.org/crypto/scarfo.html

Do you need to worry about other more generic keystroke loggers?

Do you need to worry about the fact that most user passphrases won't have enough entropy to be used directly as crypto keys? If you merely use the passphrase for salting a randomized key (such as the way gpg, ssh, and cryptLUKS use your passphrase), how do you address the problem of insufficient random entropy at key generation time?

That's just the obvious stuff you will need to worry about. :)

eCryptfs, I have this idea to design a simplified module(not another filesystem) to do transparent en/decrypting, by

Quoted 2 lines · freeman

eCryptfs, I have this idea to design a simplified module(not another filesystem) to do transparent en/decrypting, by

Doing it transparently is harder than it looks. Key management is a bitch.

(Hint - there's a reason why ecryptfs does it the way it does, rather than the simpler way you're attempting to do it...)