text: On Wed, 2 Aug 2000, I wrote:> On 2 Aug 2000, A. Ott wrote:> > > .> > You are asking for meaningless object. Filesystem may be mounted from many> places.> > > So now my problem is the following:> > > > - I have a dentry, which is the root dentry of a filesystem.> > - I want to access the (first) mount point dentry and go on to its parent> > IOW, you want meaningless behaviour. Fine.> > > I have already experimented for hours with the list > > dentry->d_sb->s_mounts, struggling with vfsmounts, list_entries and such. > > My idea was to use> > > > tmp_mnt => > list_entry(&(dentry->d_sb->s_mounts.next), struct vfsmount, mnt_list);> > new_dentry = tmp_mnt->mnt_mountpoint;> > > > but that does not work, the new_dentry value is bogus.> > Care to show the actual code? Showing what are your really trying to do> may actually help. If it's permission() hacking I'm thinking about - the> right answer is very different from what you are trying. Oh. My. $DEITY. From what I've seen in old patches it looks likepath-dependent permissions (as in "boolean function of permissions in allparents") and it's deeply alien to any UNIX. E.g. there is that littleinconvenient detail: link(2). There are symlinks and associated problems -path you are checking may have _nothing_ to the path you've passed to thekernel. Ironically, bindings may be more convenient - there, at least, youcan trace the real path. Strategy for fixing your problems: find all places where you areinterested in the path and make sure that you pass vfsmount to each ofthem (in addition to dentry). If you will show the list of such places(or, at least, ones that give you problems) there is a chance that I willbe able to help. Trying to catch _some_ parent is fundamentally bogus -you are playing with the things that are path-dependent and thus you _are_interested in the mount structure. And dentry is not an object that wouldidentify a positiion in namespace. To do that in clear way you needvfsmount - it distinguishes between different instances of fs objectobject in the namespace. Regardless of that, I have a strong gut feeling that permissionsin a point requiring the knowledge of _path_ are too alien to UNIX modelto be useful - either you have to disable a lot of things that arenormally used by basic utilities _or_ you are punching holes in yoursecurity model. But hey, it's your patch and your time... There is nofundamental problem in doing what you do with the new VFS architecture(see above for a way to do it), so...-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.rutgers.eduPlease read the FAQ at