Bug 2921 - NTTransCreate (in libcli/raw) is sent with bad parameters when in ASCII mode
Summary: NTTransCreate (in libcli/raw) is sent with bad parameters when in ASCII mode
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.0
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: All Linux
: P3 normal (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: Andrew Bartlett
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-26 11:46 UTC by Aaron Staley
Modified: 2006-03-10 09:14 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aaron Staley 2005-07-26 11:46:00 UTC
Anyhow, in libcli/raw/rawfile.c - static struct smbcli_request
*smb_raw_nttrans_create_send(struct smbcli_tree *tree,
                             union smb_open *parms)

there are two particular lines:
nt.in.params = data_blob_talloc(mem_ctx, NULL, 54);
and
SCVAL(params, 53, 0);

According to the CIFS draft, NTTransCreate is defined as:

Request Parameter Block Encoding    Description
=================================== ================================

ULONG Flags;                        Creation flags (see below)
ULONG RootDirectoryFid;             Optional directory for relative
                                     open
ACCESS_MASK DesiredAccess;          Desired access
LARGE_INTEGER AllocationSize;       The initial allocation size in
                                     bytes, if file created
ULONG ExtFileAttributes;            The extended file attributes
ULONG ShareAccess;                  The share access
ULONG CreateDisposition;            Action to take if file exists or
                                     not
ULONG CreateOptions;                Options for creating a new file
ULONG SecurityDescriptorLength;     Length of SD in bytes
ULONG EaLength;                     Length of EA in bytes
ULONG NameLength;                   Length of name in characters
ULONG ImpersonationLevel;           Security QOS information
UCHAR SecurityFlags;                Security QOS information
STRING Name[NameLength];            The name of the file (not NULL
                                     terminated)


In other words, there should be no single character padding (that is on the 53rd
byte) between Security Flags and Name.

This padding indeed causes problems when in ASCII mode (that is if
SMBCLI_FORCE_ASCII is set in the environment).  The server (samba3 or windows
2000) will see the NULL byte as the first byte as Name and will simply return
NT_STAUTS_FILE_IS_A_DIRECTORY.

Unfortunately, it appears that unicode strings are forced to be word aligned
internally (that is the smbcli_blob_append_string function and thus putstring)
and will not append starting at byte 53 (perhaps this limitation should be
removed?).  Either way, the simple solution to this problem appears to be:

change the first line to:
nt.in.params = data_blob_talloc(mem_ctx, NULL,
(tree->session->transport->negotiate.capabilities & CAP_UNICODE)?54:53);
and don't set the padding if CAP_UNICODE is not set in the capabilities
Comment 1 Stefan Metzmacher 2006-03-10 09:14:51 UTC
fixed in r14141, r14142, 14160