Stephen Smalley <[EMAIL PROTECTED]> writes: > Possibly, during setup upon initial policy load (initiated by /sbin/init > these days) from selinux_complete_init, as early userspace may have > already been accessing them.
I believe if we chose we could walk the dentry tree under the root inode and find all of these. >> If all of the accesses >> that we care about go through inode_doinit_with_dentry we can just >> walk the dcache to get the names, and that should work for the normal >> proc case as well. > > Walking the proc_dir_entry tree (or the ctl_table tree) is preferable as > it is a stable, user-immutable representation. Also avoids taking the > dcache lock. The dcache lock is valid. Since the per filesystem dentry tree is just a mirror of the filesystem data there is no advantage over using the proc_dir_entry or ctl_table tree. (If you start messing with mounts that is another matter. >> If it doesn't look easy to solve this another way I will certainly >> go with marking the inodes private. I hereby conclude this doesn't look easy enough to solve another way, to get it solved in a timely manner. Since the cost is only 2 lines of code to use private inodes if we want to fix this later it should not be difficult. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
