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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
According to [MS-RPCE].pdf, section 2.2.2.11:
----
A client or a server that (during composing of a PDU) has allocated more space
for the authentication token than the security provider fills in SHOULD fill in
the rest of the allocated space with zero octets. These zero octets are still
considered to belong to the authentication token part of the PDU.<36>
----
RPC implementations are allowed to send padding bytes at the end of an auth
footer. Windows 7 makes use of this.
Thanks to Nick Meier <nmeier@microsoft.com>
Volker
Move struct tevent_req in tevent_internal, and ad getters and setters
for private data and the callback function.
This patch also renames 'private_state' into 'data'. What is held in this
pointer is in fact data and not a state like enum tevent_req_state.
Calling it 'state' is confusing.
The functions addedd are:
tevent_req_set_callback() - sets req->async.fn and req->async.private_data
tevent_req_set_print_fn() - sets req->private_print
tevent_req_callback_data() - gets req->async.private_data
tevent_req_data() - gets rea->data
This way it is much simpler to keep API/ABI compatibility in the future.
Martin Zielinski, if you're reading this, please have a look. Vista nicely takes
just a WERR_UNKNOWN_LEVEL here and retries with a level 6 add.
Guenther
entry->num_of_strings is a uint16_t. Casting it with
(int *)&entry->num_of_strings
is wrong, because it gives add_string_to_array the illusion that the object
"num" points to is an int, which it is not.
In case we are running on a machine where "int" is 32 or 64 bits long, what
happens with that cast? "add_string_to_array" interprets the byte field that
starts where "num_of_strings" starts as an int. Under very particular
circumstances this might work in a limited number of cases: When the byte order
of an int is such that the lower order bits of the int are stored first, the
subsequent bytes which do not belong to the uint16_t anymore happen to be 0 and
the result of the increment still fits into the first 2 bytes of that int, i.e.
the result is < 65536.
The correct solution to this problem is to use the implicit type conversion
that happens when an assignment is done.
BTW, this bug is found if you compile with -O3 -Wall, it shows up as a warning:
rpc_server/srv_eventlog_lib.c:574: warning: dereferencing type-punned pointer
will break strict-aliasing rules
Thanks,
Volker
Windows 7 looks at the negotiate_flags
returned in this structure *even if the
call fails with access denied ! So in order
to allow Win7 to connect to a Samba NT style
PDC we set the flags before we know if it's
an error or not.
Jeremy.
