Re: Direct VFS/SB Access and Private Submounting

Re: Direct VFS/SB Access and Private Submounting

[Christopher Allen Wing]

Hello,

not sure if someone has written you back about this already, but what you 
are trying to do (look 'underneath' a mount point) can be done easily 
without kernel modifications.

You can bind mount an existing filesystem to a new location, and examine 
its contents without following existing mount points.

e.g. suppose you want to look at the directory on your root filesystem 
upon which /proc is mounted:

 	# mount |grep 'on /proc type proc'
 	none on /proc type proc (rw)

this is what the root of the /proc filesystem looks like:

 	# ls -ld /proc
 	dr-xr-xr-x  200 root root 0 Mar  1 18:06 /proc


Now, temporarily bind mount the root to someplace else:

 	# mkdir /tmp/look
 	# mount --bind / /tmp/look


Now you can examine the directory underlying /proc in the root:

 	# ls -ld /tmp/look/proc
 	drwxr-xr-x  2 root root 4096 Sep 26  2005 /tmp/look/proc

 	# umount /tmp/look



In general I would assume that a package manager shouldn't be concerned 
about these types of things, since permanent mountpoints should always be 
mounted when a system is in its normal state, thus there would be no 
reason to care about what's 'underneath' a mountpoint.  (If someone had 
root access, they could be hiding stuff there, but it they had root access 
they could do a whole lot of other bad things)


-Chris Wing
wingc@engin.umich.edu

Direct VFS/SB Access and Private Submounting

[John Anthony Kazos Jr.]

I'm looking for pointers to places to look (and especially documentation, 
if it exists) for how to directly access the VFS and its superblocks, and 
how to create a superblock private to my own structure.

The first part is basically this: I want to be able to create syscalls 
parallel to the normal FS calls (e.g., open()) that do not go through the 
normal dentry-walking process but instead operate on the virtual device 
ID. I imagine this would be accomplished by directly invoking the 
function pointers within a VFS superblock structure. How can I gain access 
to the superblocks, while maintaining the appropriate locking and so forth 
within the VFS? So, how can I access all currently-mounted filesystems 
without going through the normal path-parsing interface so I can access 
each filesystem irrespective of any other mountpoints? (This would allow 
me to access the directory under a mountpoint, and its contents.)

The second part is basically this: I want to be able to mount a filesystem 
without using a mountpoint. I imagine I could use the VFS function pointer 
for an FS driver with options directly instead of going through the 
mount() syscall, which would give me a superblock structure I can maintain 
and use myself without binding it to a directory. Is this correct? Again, 
I want to maintain any sort of appropriate locking necessary. (This could 
cause a problem if I obtain a superblock from a filesystem driver that 
produces shared superblocks. Is there any way to detect this? Though 
hopefully, if the driver is written appropriately, it would handle 
concurrent operations from the VFS driver already, so since I wouldn't be 
doing anything with it that the VFS wouldn't, it would still work as 
expected.)

Really, what I'm trying to do is to access the Linux VFS tree directly 
instead of by path/name strings. This is useful, to allow a package 
manager to audit the permissions and contents of directories currently 
used as mountpoints. I'm assuming some sanity checking is done, so that 
when a mountpoint is in use, the directory underneath it is marked as open 
so it cannot be deleted? (I wonder if that check is actually done, since 
it's not expected for anything to access a directory used underneath a 
mountpoint. But wouldn't the filesystem driver be able to remove the 
directory itself, especially since that driver has no idea it even is a 
mountpoint?)

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@nl.linux.org
Please read the FAQ at http://kernelnewbies.org/FAQ