On Wed, 2 Aug 2000, I wrote:
> On 2 Aug 2000, A. Ott wrote:
>
> > >From a dentry I need to find its parent dentry. As long as no mount point
> > is touched, no problem (dentry->d_parent). The mount point issue used to
> > be easily solved with a simple ->d_covers in between. Unfortunately,
> > d_covers has been silently removed in 2.4.0-test1.
>
> 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 like
path-dependent permissions (as in "boolean function of permissions in all
parents") and it's deeply alien to any UNIX. E.g. there is that little
inconvenient detail: link(2). There are symlinks and associated problems -
path you are checking may have _nothing_ to the path you've passed to the
kernel. Ironically, bindings may be more convenient - there, at least, you
can trace the real path.
Strategy for fixing your problems: find all places where you are
interested in the path and make sure that you pass vfsmount to each of
them (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 will
be 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 would
identify a positiion in namespace. To do that in clear way you need
vfsmount - it distinguishes between different instances of fs object
object in the namespace.
Regardless of that, I have a strong gut feeling that permissions
in a point requiring the knowledge of _path_ are too alien to UNIX model
to be useful - either you have to disable a lot of things that are
normally used by basic utilities _or_ you are punching holes in your
security model. But hey, it's your patch and your time... There is no
fundamental 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" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Aug 07 2000 - 21:00:10 EST