Quantcast

[PATCH] copy-chunk fails if src and dst file are on different tcons

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[PATCH] copy-chunk fails if src and dst file are on different tcons

Samba - samba-technical mailing list
Hi!

As the subject says, this fails against Samba but works against
Windows. Verified against Windows 2016.

Attached is a possible fix plus test.

Please review & push if happy. Thanks!

-slow

bug12752-master.patch (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] copy-chunk fails if src and dst file are on different tcons

Samba - samba-technical mailing list
On Fri, Apr 21, 2017 at 12:55:55PM +0200, Ralph Böhme via samba-technical wrote:
> Hi!
>
> As the subject says, this fails against Samba but works against
> Windows. Verified against Windows 2016.
>
> Attached is a possible fix plus test.
>
> Please review & push if happy. Thanks!

please ignore for now. metze raised an issue over private RPC dealing with the
VFS handles that we end up using in the send functions.

-slow

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] copy-chunk fails if src and dst file are on different tcons

Samba - samba-technical mailing list
On Fri, Apr 21, 2017 at 04:52:10PM +0200, Ralph Böhme wrote:

> On Fri, Apr 21, 2017 at 12:55:55PM +0200, Ralph Böhme via samba-technical wrote:
> > Hi!
> >
> > As the subject says, this fails against Samba but works against
> > Windows. Verified against Windows 2016.
> >
> > Attached is a possible fix plus test.
> >
> > Please review & push if happy. Thanks!
>
> please ignore for now. metze raised an issue over private RPC dealing with the
> VFS handles that we end up using in the send functions.
metze, maybe we can just do the check at the vfs layer. See attached patch for
the basic idea. Should be expanded to cover all vfs functions that take a fsp
and a vfs handle.

Just fetching and "looking" at an fsp at the smb layer should be possible, it's
where we start using it where we should check. Or am I still missing something?

-slow
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] copy-chunk fails if src and dst file are on different tcons

Samba - samba-technical mailing list
On Fri, Apr 21, 2017 at 06:39:38PM +0200, Ralph Böhme via samba-technical wrote:

> On Fri, Apr 21, 2017 at 04:52:10PM +0200, Ralph Böhme wrote:
> > On Fri, Apr 21, 2017 at 12:55:55PM +0200, Ralph Böhme via samba-technical wrote:
> > > Hi!
> > >
> > > As the subject says, this fails against Samba but works against
> > > Windows. Verified against Windows 2016.
> > >
> > > Attached is a possible fix plus test.
> > >
> > > Please review & push if happy. Thanks!
> >
> > please ignore for now. metze raised an issue over private RPC dealing with the
> > VFS handles that we end up using in the send functions.
>
> metze, maybe we can just do the check at the vfs layer. See attached patch for
> the basic idea. Should be expanded to cover all vfs functions that take a fsp
> and a vfs handle.
>
> Just fetching and "looking" at an fsp at the smb layer should be possible, it's
> where we start using it where we should check. Or am I still missing something?

Just my 2cents. This looks like the right approach but does mean
changing all of the fsp-based VFS calls. Is there
any way to do this above the VFS layer (haven't thought too
deeply about this yet) ?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] copy-chunk fails if src and dst file are on different tcons

Samba - samba-technical mailing list
On Fri, Apr 21, 2017 at 02:21:41PM -0700, Jeremy Allison wrote:

> On Fri, Apr 21, 2017 at 06:39:38PM +0200, Ralph Böhme via samba-technical wrote:
> > On Fri, Apr 21, 2017 at 04:52:10PM +0200, Ralph Böhme wrote:
> > > On Fri, Apr 21, 2017 at 12:55:55PM +0200, Ralph Böhme via samba-technical wrote:
> > > > Hi!
> > > >
> > > > As the subject says, this fails against Samba but works against
> > > > Windows. Verified against Windows 2016.
> > > >
> > > > Attached is a possible fix plus test.
> > > >
> > > > Please review & push if happy. Thanks!
> > >
> > > please ignore for now. metze raised an issue over private RPC dealing with the
> > > VFS handles that we end up using in the send functions.
> >
> > metze, maybe we can just do the check at the vfs layer. See attached patch for
> > the basic idea. Should be expanded to cover all vfs functions that take a fsp
> > and a vfs handle.
> >
> > Just fetching and "looking" at an fsp at the smb layer should be possible, it's
> > where we start using it where we should check. Or am I still missing something?
>
> Just my 2cents. This looks like the right approach but does mean
> changing all of the fsp-based VFS calls.

d'oh! Most VFS macros that take an fsp don't take a conn directly anyway, instead
the macro pulls the vfs handle out of the fsp (fsp->conn->vfs_handles). Which is
exactly what we want.

There are a few VFS macros that don't adhere to this scheme (eg
SMB_VFS_GET_ALLOC_SIZE, SMB_VFS_STREAMINFO, SMB_VFS_STRICT_LOCK,
SMB_VFS_COPY_CHUNK_SEND), but I guess that's not an purpose and could be fixed.

Thinking more about it, my change would result in VFS calls running with their
curdir set to a different tcon then their fsp. We currently rely on doing a
chdir to the share root when processing an smb req for a tcon, don't we? This
might actually sink my ship. I imagine shadow_copy2 might not be happy when
processing a request to read from an fsp that is assodicated with tcon 1 while
the curdir is the share root of tcon 2. Hm.

> Is there any way to do this above the VFS layer (haven't thought too deeply
> about this yet) ?

Short of adding special casing this by adding a read/write loop at the smb
layer: I don't think so.

-slow

Loading...