[cifs-protocol] [REG:110092975377470] "Issue 2" (was "Summary of [MS-BKRP] 3.1.4.1.4 BACKUPKEY_RESTORE_GUID issues")

Bryan Burgin bburgin at microsoft.com
Wed Sep 29 16:55:08 MDT 2010


[Merging threads]
[Adding cifs-protocol at samba.org; Nick Meier  pfif at tridgell.net]

Matthieu,

Regarding this issue on a separate thread, you added:

"Bryan do you remember with which server do we have this ? because today with a w2k8 server I keep receiving WERR_IO_PENDING (0x000003E5) It seems to be w2k8r2 (for ERROR_INVALID_DATA). In fact it seems that we have IO_PENDING up to w2k8 included and then INVALID_DATA."

We were using Server 2008 R2.  Can you get a TT Trace with Server 2008 SP2 that shows WERR_IO_PENDING (0x000003E5) and I'll add that as a Windows behavior after researching the issue?

As an implementer of the protocol, you should return ERROR_FILE_NOT_FOUND (2), as is recommended in the specification:

[MS-BKRP] 3.1.4.1.4 Step 1:
"Retrieve the ClientWrap key pair corresponding to the GUID specified by the guidKey field. If the key pair cannot be retrieved, the server MUST return an appropriate nonzero error code. The error code returned SHOULD be equal to ERROR_FILE_NOT_FOUND (0x2)."

Bryan

From: Bryan Burgin
Sent: Wednesday, September 29, 2010 3:36 PM
To: 'mat at samba.org'; Hongwei Sun
Cc: MSSolve Case Email
Subject: [REG:110092975377470] "Issue 2" (was "Summary of [MS-BKRP] 3.1.4.1.4 BACKUPKEY_RESTORE_GUID issues")


Matthieu,

Regarding "Issue 2" (see mail below), I was able to verify that Server 2008 R2 does return ERROR_INVALID_DATA 0xd (14) in this scenario instead of the recommended ERROR_FILE_NOT_FOUND (0x2)."  I filed a request with the product group to document that Server 2008 R2.

The function that actually discovers the error properly returns STATUS_OBJECT_NAME_NOT_FOUND ((NTSTATUS)0xC0000034L) to its immediate caller, but does not call SetLastError().  The failure rolls back to previous callers as a Boolean fail/succeed instead of passing back the NTSTATUS code.  A middle-level function knows that there was a failure (based on the Boolean that was passed back) and calls GetLastError() to determine its cause.  Since the Last Error was never set, that comes back as zero (STATUS_SUCCESS).  Since the middle-level function doesn't have an exact cause, it falls back to returning ERROR_INVALID_DATA (0xd).  STATUS_OBJECT_NAME_NOT_FOUND ((NTSTATUS) 0xC0000034L), which would map to the Win32 error ERROR_FILE_NOT_FOUND (0x2), never gets communicated.

Our repro was with Server 2008 R2.  I suspect that this is the same across all the server versions.

I recommended the behavior note:

[MS-BKRP] 3.1.4.1.4 Step 1:

"Retrieve the ClientWrap key pair corresponding to the GUID specified by the guidKey field. If the key pair cannot be retrieved, the server MUST return an appropriate nonzero error code. The error code returned SHOULD be equal to ERROR_FILE_NOT_FOUND (0x2). <nn>"

"<nn> Windows Server 2008 R2 (and others) return ERROR_INVALID_DATA (0x0000000D)."

If accepted, it will show up in a future update to MS-BKRP.

Bryan

From: Bryan Burgin
Sent: Tuesday, September 28, 2010 11:35 AM
To: 'mat at samba.org'; Hongwei Sun
Subject: Summary of [MS-BKRP] 3.1.4.1.4 BACKUPKEY_RESTORE_GUID issues

Matthieu,

[...]


ISSUE TWO
===========


x64 08R2 TTTrace at C:\CustomerFiles\Samba_backupkey\lsass03.run
Issue: BACKUPKEY_RESTORE_GUID step #1:

    "Retrieve the ClientWrap key pair corresponding to the GUID specified by the guidKey field.
    If the key pair cannot be retrieved, the server MUST return an appropriate nonzero error
    code. The error code returned SHOULD be equal to ERROR_FILE_NOT_FOUND (0x2)."

Expecting ERROR_FILE_NOT_FOUND 0x2 (2)
Receiving ERROR_INVALID_DATA 0xd (14)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20100929/f68e3784/attachment-0001.html>


More information about the cifs-protocol mailing list