[PATCH 0/13] add SMB2 server-side copy support - V2

[Jeremy Allison]

On Thu, Dec 06, 2012 at 10:24:19PM +0100, David Disseldorp wrote:
> Hi Jeremy,
> 
> On Thu, 6 Dec 2012 09:53:52 -0800
> Jeremy Allison <jra at samba.org> wrote:
> 
> > > Strangely Windows servers do not appear to check the open-time granted
> > > access on the source file. This behaviour matches what is documented in
> > > [MS-SMB2] 3.3.5.15.6 Handling a Server-Side Data Copy Request, where
> > > only the destination file is checked for open-time granted read and
> > > write access.
> > > 
> > > I'll drop the src_fsp check for now, dest_fsp will be checked for read
> > > and write access. New round of patches with a bunch more torture tests
> > > is on its way.  
> > 
> > I don't think we can do that can we ?
> > 
> > Imagine the following, a "super-secure" file is opened with READ_ATTRIBUTES
> > only, then used as a copychunk source handle to copy data from it into a
> > "non-secure" file.
> 
> Wouldn't the super-secure file ACL block the read at IO time anyway?
> The copychunk default VFS hooks still uses regular read/write to perform
> the offloaded IO.

No - there are no checks on ACLs at IO time - that would be very
slow !

We check at open handle time, and also at the SMB/SMB2/SMB3 layer
then assume that it's ok in the VFS layer. So if you're using
VFS calls you need to have done the handle check first.

> Here's the test case written to exercise this behaviour:
> https://git.samba.org/?p=ddiss/samba.git;a=blob;f=source4/torture/smb2/ioctl.c;h=273ac36fd0d995459eee38bf7f00a4f432c212a0;hb=ec757abee90c0ed350cf97130535dba59b6171bc#l1124
> 
> > I think we have to have the read check on the source file.
> 
> I'm fine with adding the read check, but it means we will diverge from
> (strange) Windows behaviour in this case.

I'd be really interested if you can open a Windows
served file that has no FILE_READ_DATA access with
a different open access_mask and then use it as a
copychunk read source. If you can that looks like
a security violation to me.

Jeremy.