The semantics of paths in VFS modules

[Jeremy Allison]

On Sun, Apr 03, 2016 at 12:42:08PM -0700, Richard Sharpe wrote:
> On Sun, Apr 3, 2016 at 12:05 PM, Uri Simchoni <uri at samba.org> wrote:
> > On 04/02/2016 11:17 PM, Richard Sharpe wrote:
> >> On Sat, Apr 2, 2016 at 12:54 PM, Uri Simchoni <uri at samba.org> wrote:
> >>> Hi,
> >>>
> >>> I would like to document the meaning of path names in the wiki
> >>> (add it to the vfs module writing page), and thought I'd first submit it
> >>> to the list to get comments.
> >>
> >> In general I like it.
> >>
> >> There are some special cases, I think, such as if you allow wide
> >> links, then Samba cannot use paths relative to the root of the share.
> >>
> >> Maybe it falls under what you have already written.
> > Thanks for reading and commenting.
> >
> > I haven't covered this one, and should probably write something about
> > wide links (I intend to cover more semantics of individual functions and
> > this can fall under realpath). However, it appears to me that even if
> > wide links are allowed, smbd would not, as a result, hand paths which
> > are not relative to the share's root to VFS modules.
> >
> > I mean, if we have "foo" --> /etc/shadow, then the SMB operations are on
> > foo, and so are the resulting VFS operations. There's realpath_fn which
> > would *return* /etc/shadow, but smbd would use the return val only for
> > comparison and not pass it on to other VFS modules.
> >
> > Please correct me if I'm wrong.
> 
> Hmmm, I don't know. I will have to look, and perhaps Samba simply
> passes the original name to SMB_VFS_OPEN, in which case there is not a
> problem.

Yes, Samba shouldn't be passing the realpath return into the VFS
functions (and I don't think it does).