What is the guarantee around path names in calls to VFS functions

[Volker Lendecke]

On Thu, Jun 25, 2015 at 09:59:58AM -0700, Richard Sharpe wrote:
> On Wed, Jun 24, 2015 at 11:30 PM, Volker Lendecke
> <Volker.Lendecke at sernet.de> wrote:
> > On Wed, Jun 24, 2015 at 10:04:27PM -0700, Richard Sharpe wrote:
> >> Hi folks,
> >>
> >> I thought that the guarantee was that the paths passed to VFS
> >> functions is that they would be relative to the root of the share.
> >> This would be a nice guarantee. Or else, it would be nice if they were
> >> all absolute paths.
> >>
> >> However, it seems that sometimes they are relative to the root of the
> >> share, and sometimes they are absolute and sometimes they are even
> >> outside the share path.
> >>
> >> Examples include calls to SMB_VFS_NEXT_XXX in, say, vfs_shadow_copy2.c
> >> when a path in the snapshot file system is constructed, or paths in
> >> the vfs_streams_depot.c module when you place them outside the share
> >> directory so users cannot clobber them.
> >
> > Well, the whole point of shadow_copy2 is to make paths
> > outside the share available as snapshots. How would you make
> > that functionality available if not by accessing paths
> > outside the share? I would really, really be curious how
> > your installation can do this. Do you have special APIs to
> > access snapshots outside the share path given only paths
> > within the share path? I've been deep inside shadow_copy2,
> > and I would *LOVE* to know about that API.
> >
> > Thanks a lot in advance for this information!!!
> 
> I think you misunderstood my question.
> 
> I am seeking a simple model of paths that come down the VFS.
> 
> Yes, it is clear that things like Shadow-Copy and streams-depot have
> to generate paths that are outside the share, but by calling functions
> like SMB_VFS_NEXT_XXX with relative paths some times and absolute
> paths other times we are burdening modules lower in the stack with
> figuring out the difference.
> 
> It gets worse, because sometimes those absolute paths are actually
> within the share, so we cannot use simple assumptions like if the path
> starts with '/' it is outside the share.
> 
> In addition, if you know that the path is outside the share why not
> use sys_xxx rather than SMB_VFS_NEXT ... because the next module
> should not be interested in that path at all?

Ok, got you now. I don't have a good idea yet how we can
enforce this properly. Maybe we need to put in a completely
fresh second vfs layer that is what the VFS used to be:
Strictly posix based. There we can then have global,
absolute path based VFS modules, much like the kernel mount
points are aligned, but only in user space. Is that what you
have in mind?

Volker

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de