I'm working on a Linux filesystem driver and I've got the hang of generating a superblock, creating inodes and dentry's, and making them handle reads and writes.
Now, though, I want the driver to be able to present new files to the user dynamically. Basically, my question is: how can I do this?
Let's say, for a silly example, every time the user reads from a file, we create a new file. Intuitively, I would want to just create a new inode and dentry, and link them together. The problem here is that in my file reading callback function I have no access to the superblock (I think), which means I can't make a new inode.
I won't post the code for my driver since it's too long, even to create a minimal example, but for a general overview: the file_system_type struct's mount function calls mount_nodev, and then in my function to fill the superblock I setup the root directory and create a file named "file1".
Thanks in advance :)
Based on information from a comment by #Tsyvarev, I can indeed create a file dynamically in the same exact fashion as when I first set up the filesystem, taking the superblock from the struct file*'s linked inode!
Related
I am currently developing a simple kernel module that can steal system calls such as open, read, write and replace them with a simple function which logs the files being opened, read, written, into a file and return the original system calls.
My query is, I am able to get the File Descriptor in read and write system calls, but I am not able to understand how to obtain file name using the same.
Currently I am able to access the file structure associated with given FD using following code:
struct file *file;
file = fcheck(fd);
This file structure has two important entities in it, which are of my concern I believe:
f_path
f_inode
Can anybody help me get dentry or inode or the path name associated with this fd using the file structure associated with it?
Is my approach correct? Or do I need to do something different?
I am using Ubuntu 14.04 and my kernel version is 3.19.0-25-generic, for the kernel module development.
.f_inode is actually an inode.
.f_path->dentry is a dentry.
Traversing this dentry via ->d_parent link, until f_path.mnt.mnt_root dentry will be touched, and collecting dentry->d_name components, will construct the file's path, relative to the mount point. This is done, e.g., with d_path, but in more carefull way.
Instead of fcheck(fd), which should be used inside RCU read section, you can also use fget(fd), which should be paired with fput().
The approach is completely incorrect - see http://www.watson.org/~robert/2007woot/
Linux already has a reliable mechanism for doing this thing (audit). If you want to implement it anyway (for fun I presume), you want to place your hooks roughly where audit is doing that. Chances are LSM hooks are in appropriate places, have not checked.
I am currently working on an antiroot-kit for android as a student project. My task is to identify hidden files on the filesystem.
Therefore, I want to read the contents of a directory in a kernel module to compare it with the contents of a directory an app might see in usermode (which is probably censored by a rootkit). I know that file IO is generally a bad idea in kernel mode but I think this might be an exception.
I used filp_open to open a file and get a struct file. With this I was able to get the inode and dentry structures of the file. I was not able to get the contents of a directory this way. I thought there must be a function for it.
I searched on stackoverflow and found the vfs_readdir function. The problem is that I have not understood how to use this function. What do I set for the filldir_t parameter and what do I set for the buffer? How do I retrieve the contents of a directory in a kernelmodule? Can somebody provide an example? I could not find an easy example on the internet and in the linux kernel.
Hello I am a newbie to kernel programming. I am writing a small kernel module
that is based on wrapfs template to implement a backup mechanism. This is
purely for learning basis.
I am extending wrapfs so that when a write call is made wrapfs transparently
makes a copy of that file in a separate directory and then write is performed
on the file. But I don't want that I create a copy for every write call.
A naive approach could be I check for existence of file in that directory. But
I think for each call checking this could be a severe penalty.
I could also check for first write call and then store a value for that
specific file using private_data attribute. But that would not be stored on
disk. So I would need to check that again.
I was also thinking of making use of modification time. I could save a
modification time. If the older modification time is before that time then only
a copy is created otherwise I won't do anything. I tried to use inode.i_mtime
for this but it was the modified time even before write was called, also
applications can modify that time.
So I was thinking of storing some value in inode on disk that indicates its
backup has been created or not. Is that possible? Any other suggestions or
approaches are welcome.
You are essentially saying you want to do a Copy-On-Write virtual filesystem layer.
IMO, some of these have been done, and it would be easier to implement these in userland (using libfuse and the fuse module, e.g.). That way, you can be king of your castle and add your metadata in any which way you feel is appriate:
just add (hidden) metadata files to each directory
use extended POSIX attributes (setfattr and friends)
heck, you could even use a sqlite database
If you really insist on doing these things in-kernel, you'll have a lot more work since accessing the metadata from kernel mode is goind to take a lot more effort (you'd most likely want to emulate your own database using memory mapped files so as to minimize the amount of 'userland (style)' work required and to make it relatively easy to get atomicity and reliability right1.
1
On How Everybody Gets File IO Wrong: see also here
You can use atime instead of mtime. In that case setting S_NOATIME flag on the inode prevents it from updating (see touch_atime() function at the inode.c). The only thing you'll need is to mount your filesystem with noatime option.
my question is probably again pretty simple, but I did not find anything. I am writing a Linux Security Module. As you might know the struct inode in the kernel contains one field i_security to save security relevant information for the LSM. Now just to make sure: Is it safe to assume that no user (not even root) will be able to read or write this value, i.e. can this value really be accessed only from kernel space?
The reason for my question is, that it is obvious that some inode data can be accessed from userspace (through systemcalls I guess, but still using chmod etc. you are able to change some values in an inode) and now I wonder if that doesn't mean, that all inode data (also the i_security) can be accessed from user space somehow.
Cheers
Yes. You can use grep or ack to scan kernel code for i_security, and you can find it is modified only by files under security/ directory, and cannot be modified by user applications, since they have no direct access to the i_security field.
I am writing a program consisting of user program and a kernel module. The kernel module needs to gather data that it will then "send" to the user program. This has to be done via a /proc file. Now, I create the file, everything is fine, and spent ages reading the internet for answer and still cannot find one. How do you read/write a /proc file from the kernel space ? The write_proc and read_proc supplied to the procfile are used to read and write data from USER space, whereas I need the module to be able to write the /proc file itself.
That's not how it works. When a userspace program opens the files, they are generated on the fly on a case-by-case basis. Most of them are readonly and generated by a common mechanism:
Register an entry with create_proc_read_entry
Supply a callback function (called read_proc by convention) which is called when the file is read
This callback function should populate a supplied buffer and (typically) call proc_calc_metrics to update the file pointer etc supplied to userspace.
You (from the kernel) do not "write" to procfs files, you supply the results dynamically when userspace requests them.
One of the approaches to get data across to the user space would be seq_files. In order to configure (write) kernel parameters you may want to consider sys-fs nodes.
Thanks,
Vijay