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

[Richard Sharpe]

On Thu, Jun 25, 2015 at 12:20 PM, Volker Lendecke
<Volker.Lendecke at sernet.de> wrote:
> 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?

I haven't thought it through that far yet, but I suspect that
something like that will be needed.

I am exploring the issues at the moment.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)