[PATCH 0/13] add SMB2 server-side copy support - V2
jra at samba.org
Thu Dec 6 14:57:36 MST 2012
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] 220.127.116.11.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
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:
> > 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.
More information about the samba-technical