IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
(this does not change the file server role, and only really changes
what 'server signing = auto' means)
Optional signing really isn't any benifit to network security.
In doing so, allow anonymous clients (if permitted by policy) to log
in without signing, as Samba3 does not sign these connections (which
would use an all-zero key, so pointless).
Andrew Bartlett
(This used to be commit 468bf839c500ed1a26ab9a358ee64a4c0a695797)
We need to use smbsrv_setup_secondary_request(req) to send the
trans ack, because smbsrv_send_reply(req) destroys 'req'
and the partial trans list had dead elements in the list.
Also make sure the partial list element is removed by a talloc
destructor.
metze
(This used to be commit 221f4d6e534a40b7def6e51dc6b4f9e8057d18b7)
If smb_messages flags show for which opcodes VWV(0)
signifies chaining modes, and also which opcodes can
have requests >64K then the bcc / req->in.data_size
fixup in smbsrv_recv_smb_request can be more safely
applied.
This fix permits nttrans requests >64K to be handled.
It is not yet clear if THAT is a good thing, but this
fix does the current thing more nicely.
(This used to be commit 8e4f16e975e192709f398c98650cbe9fe2a76261)
No functional change, just re-ordering so that
smbsrv_recv_smb_request can refer to smb_messages
in a future patch
(This used to be commit d06eafea1a3e7fa61c94492cf504e6fd81da861d)
Erroneous 16bit storage for nttrans counts meant that nttrans behaved
"strangely" for sizes of over 64K
As 32 bit is used in the SMB message and specified in
http://us4.samba.org/samba/ftp/specs/draft-leach-cifs-v1-spec-02.txt
section 3.13.2
this fix changes storage to match.
Signed-off-by: Amin Azez <azez@ufomechanic.net>
(This used to be commit d66b6c3823f003875e3b7cdf63617a894cceadf9)
Note that we don't use any protocol specific values here.
For now only NTVFS_CLIENT_CAP_LEVEL_II_OPLOCKS is defined
others should be defined, when we find out that the ntvfs
layer needs to know about it.
metze
(This used to be commit cc42cd5f6753ca582677fa6f403f0419eec5ab10)
We needed a flag in bufinfo to mark packets as SMB2, as it seems that
SMB2 uses a different format for the RenameInformation buffer than SMB
does
Also handle the fact that SMB2 clients give the full path to the
target file in the rename, not a relative path
(This used to be commit 52d7972d95ddc19d22a4187b4d4428a6c3ed32d5)
This converts our SMB and SMB2 code to use a common structure "struct
request_bufinfo" for information on the buffer bounds of a packet,
alignment information and string handling. This allows us to use a
common backend for SMB and SMB2 code, while still using all the same
string and blob handling functions.
Up to now we had been passing a NULL req handle into these common
routines from the SMB2 side of the server, which meant that we failed
any operation which did a bounds checked string extraction (such as a
RenameInformation setinfo call, which is what Vista uses for renaming
files)
There is still some more work to be done on this - for example we can
now remove many of the SMB2 specific buffer handling functions that we
had, and use the SMB ones.
(This used to be commit ca6d9be6cb6a403a81b18fa6e9a6a0518d7f0f68)
fixed the input side of the SMB2 negprot structure and parsers according to the documentation
(This used to be commit 55af8acc7b32c24e4b1187e9d8d1c8f060e914b0)
req_grow_data was growing the original req, not this_req which
was being used for the current fragment.
(This used to be commit 2ac47f5ab670f971f41f99700dbfb3655fd6737f)
