Age | Commit message (Collapse) | Author | Files | Lines |
|
of security descriptors.
As pointed out by an OEM, the code within smbd/posix_acl.c, even though passed
a const pointer to a security descriptor, still modifies the ACE entries within
it (which are not const pointers).
This means ACLs stored in the extended attribute by the acl_xattr module have
already been modified by the POSIX acl layer, and are not the original intent
of storing the "unmodified" ACL from the client.
Use dup_sec_desc to make a copy of the incoming ACL on talloc_tos() - that
is what is then modified inside smbd/posix_acl.c, leaving the original ACL
to be correctly stored in the xattr.
Jeremy.
Autobuild-User: Jeremy Allison <jra@samba.org>
Autobuild-Date: Fri Oct 8 00:37:53 UTC 2010 on sn-devel-104
|
|
This fixes a crash in the echo responder when the client started to send the
NetBIOS-Level 0x85-style keepalive packets. We did not correctly check the
packet length, so the code writing the signing seqnum overwrote memory after
the malloc'ed area for the 4 byte keepalive packet.
Autobuild-User: Jeremy Allison <jra@samba.org>
Autobuild-Date: Thu Oct 7 19:47:35 UTC 2010 on sn-devel-104
|
|
in the destination struct for a rename, so set the flag appropriately.
Jeremy.
|
|
Without this, we can get a writable pipe end, but the writev call on the pipe
will block.
Autobuild-User: Volker Lendecke <vlendec@samba.org>
Autobuild-Date: Wed Oct 6 13:57:30 UTC 2010 on sn-devel-104
|
|
in the destination struct for a rename, so set the flag appropriately.
Jeremy.
Autobuild-User: Jeremy Allison <jra@samba.org>
Autobuild-Date: Wed Oct 6 00:29:51 UTC 2010 on sn-devel-104
|
|
Autobuild-User: Volker Lendecke <vlendec@samba.org>
Autobuild-Date: Tue Oct 5 10:09:38 UTC 2010 on sn-devel-104
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is a place where an explicit dmapi_destroy_session would be needed. But we
don't use a destructor for this.
|
|
Even printing once per connection, level 0 was too spammy with
Windows clients frequently sending FSCTL_GET_OBJECT_ID which
is unsupported.
|
|
Previously, only one fd handler was being called per main message loop
in all smbd child processes.
In the case where multiple fds are available for reading the fd
corresponding to the event closest to the beginning of the event list
would be run. Obviously this is arbitrary and could cause unfairness.
Usually, the first event fd is the network socket, meaning heavy load
of client requests can starve out other fd events such as oplock
or notify upcalls from the kernel.
In this patch, I have changed the behavior of run_events() to unset
any fd that it has already called a handler function, as well
as decrement the number of fds that were returned from select().
This allows the caller of run_events() to iterate it, until all
available fds have been handled.
I then changed the main loop in smbd child processes to iterate
run_events(). This way, all available fds are handled on each wake
of select, while still checking for timed or signalled events between
each handler function call. I also added an explicit check for
EINTR from select(), which previously was masked by the fact that
run_events() would handle any signal event before the return code
was checked.
This required a signature change to run_events() but all other callers
should have no change in their behavior. I also fixed a bug in
run_events() where it could be called with a selrtn value of -1,
doing unecessary looping through the fd_event list when no fds were
available.
Also, remove the temporary echo handler hack, as all fds should be
treated fairly now.
|
|
Guenther
|
|
If select returns -1, we can't rely on the fd sets. The current code might loop
endlessly because when putting an invalid fd (the closed socket?) on the read
set, a select implementation might choose not to touch it but directly return
with EINVAL. Thus run_events will see the socket readable, which leads to a
"return true", and thus a NT_STATUS_RETRY -> same game again.
We should never get into this situation, but to me the logfiles given in bug
7518 do not reveal enough information to understand how this can happen.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
req==NULL should never happen, see the comment
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NetBIOS session request.
Don't just fail to reply on a bad NBT name, just don't do the
internal action.
Jeremy.
|
|
TDB_CLEAR_IF_FIRST tdb's. For tdb's like gencache where we open
without CLEAR_IF_FIRST and then with CLEAR_IF_FIRST if corrupt
this is still safe to use as if opening an existing tdb the new
hash will be ignored - it's only used on creating a new tdb not
opening an old one.
Jeremy.
|
|
|
|
|