On Fri, Sep 9, 2011 at 12:06 PM, Shawn Johnson <shcjohn...@gmail.com> wrote: > > Thanks for the reply Lucas; I know your working on all kinds of things. > > I have a couple of questions, A file is create that has all the hidden inode > numbers. How is that file constructed and how does it store the data. > > ########################################################### > > tune2fs -l /dev/sda2 > > tune2fs 1.40.2 (12-Jul-2007) > > Filesystem volume name: > > Last mounted on: > > Filesystem UUID: 8c2da865-13f4-47a2-9c92-2f31738469e8 > > Filesystem magic number: 0xEF53 > > Filesystem revision #: 1 (dynamic) > > Filesystem features: has_journal resize_inode dir_index filetype > needs_recovery sparse_super large_file > > Filesystem flags: signed directory hash > > Default mount options: (none) > > Filesystem state: clean > > Errors behavior: Continue > > Filesystem OS type: Linux > > Inode count: 12222464 > > Block count: 24412775 > > Reserved block count: 1220638 > > Free blocks: 17464715 > > Free inodes: 12055081 > > First block: 0 > > Block size: 4096 > > Fragment size: 4096 > > Reserved GDT blocks: 1018 > > Blocks per group: 32768 > > Fragments per group: 32768 > > Inodes per group: 16384 > > Inode blocks per group: 512 > > Filesystem created: Sat Oct 6 04:51:23 2007 > > Last mount time: Fri Nov 9 08:07:04 2007 > > Last write time: Fri Nov 9 08:07:04 2007 > > Mount count: 12 > > Maximum mount count: 32 > > Last checked: Mon Nov 5 13:33:36 2007 > > Check interval: 15552000 (6 months) > > Next check after: Sat May 3 13:33:36 2008 > > Reserved blocks uid: 0 (user root) > > Reserved blocks gid: 0 (group root) > > First inode: 11 > > Inode size: 128 > > Journal inode: 8 > > First orphan inode: 1163400 > > Default directory hash: tea > > Directory Hash Seed: bcaf359b-11c2-4c1a-8823-92be72c09ac4 > > Journal backup: inode blocks > > > > I guess the file would have to be constructed like. > > Filesystem > UUID: > Inode > > 8c2da865-13f4-47a2-9c92-2f31738469e8 > XXXXX > > Or > > Each filesystem UUID would have its own file with the hidden inodes > > What do you think > > Thanks Shawn
Hi Shawn, Not all filesystems export an UUID, so that alternative would only work for a few of them. In the current implementation, when the user requests to request a symlink or directory, we: [in user space] 1. Get that object's inode number and its pathname and send that to the kernel through an ioctl; [in kernel space] 2. Walk through the file system tree to convert the pathname into a "struct path", which is saved in the lookup structure. The struct path will get us two identifiers: the dentry associated to the pathname and its mountpoint; 3. Save the pathname in the lookup structure; 4. Save the inode number in the lookup structure, taking special care in the case of stackable filesystems (unionfs); 5. Link that lookup structure in the linked list. In order to find if a file is already being hidden or not, we use the inode number and the dentry that we want to check. We then iterate the linked list and perform the each verification for each entry on that list: 1. Compare the provided inode number with the list entry's inode number; 2. Compare the provided dentry's superblock with the list entry's one; 3. Compare the length of the file name's of the two dentries; 4. Walk the file system tree from the dentry objects up to their root dentry. If the result points us to the same root dentry then it's assumed that the provided dentry matches the one we have in the list. In that case, the dentry's name is not copied to the result of readdir(). So, in theory, the combination of the inode number with the memory address where the superblock structure has been loaded to should do the work. I just don't remember why step 4 is being performed. It doesn't seem necessary, and I believe it can lead to some false negatives. If you have time to test this, could you please take the latest Linux 3.0.4 recipe and apply the patch which finds attached on the top of the original gobohide? My intuition is that the mount points that you were trying to hide will get hidden this time. Please let me know if it works. I haven't tried to build it, so please take care of any minor compiler messages regarding this change. Thanks, -- Lucas "If you're looking for a reason I've a reason to give: pleasure, little treasure"
gobohide_get_unlocked.patch
Description: Binary data
_______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
