Re: misuse of pathnames in rump (and portalfs?)

[David Holland <dholland-tech%netbsd.org@localhost>]

On Wed, Nov 24, 2010 at 07:32:42PM +0200, Antti Kantee wrote:
 > > Furthermore, it is just plain gross for the behavior of VOP_LOOKUP in
 > > some directory to depend on how one got to that directory. As a matter
 > > of design, the working path should not be available to VOP_LOOKUP and
 > > VOP_LOOKUP should not attempt to make use of it.
 > > 
 > > When I asked pooka for clarification, I got back an assertion that
 > > portalfs depends on this behavior so I should rethink the namei design
 > > to support it. However, as far as I can tell, this is not true: there
 > > is only one unexpected/problematic use of the pathname buffer in
 > > question anywhere in the system, in rumpfs.c. Furthermore, even if it
 > > were true, I think it would be highly undesirable.
 > 
 > You wrote that the whole path will no longer be available.  As you
 > say yourself, it doesn't make sense for a file system to care about
 > the previous components, so don't be shocked that I took this to
 > mean the whole remaining path.  If the whole remaining path is
 > available, portalfs should be fine.

I don't remember exactly what I wrote, but I'm pretty sure I
explicitly said it was using the whole namei work buffer. Perhaps it
could have been clearer.

I don't see that exposing the whole remaining path is desirable
either, but that's a different argument.

 > As for etfs, as you might be able to see from the code, it's only used
 > for root vnode lookups.  I cannot think of a reason why we cannot define
 > the key to start with exactly one leading '/'.  Some in-tree users may
 > not follow that rule now, but they should be quite trivial to locate
 > with grep.  That should make it work properly with your finally-nonbroken
 > namei and also take care of all symlink/.. concerns you might have.

I think it makes more sense for doregister to check for at least one
leading '/' and remove the leading slashes before storing the key.
Then the key will match the name passed by lookup; otherwise the
leading slash won't be there and it won't match. (What I suggested
last night is broken because it doesn't do this.)

All users I can find pass an absolute path.

-- 
David A. Holland
dholland%netbsd.org@localhost