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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Previously we relied on process groups and SIGTERM to ensure that
child tasks died in the standard process model when the parent task
died. This doesn't work when the server is run in interactive mode, as
in that case we don't call become_daemon() and don't get a separate
process group.
The fix is to have a pipe held open by the parent server process, and
inherited by child tasks. If the parent exits then the write side of
the pipe is implicitly closed, which causes an event in the child
tasks that causes them to exit
While testing the use of the standard process model with 'make test' I
found that testing was much slower (by several times) with the
standard model than with the single model. The primary problem was
that each SMB connection would open a new sam ldb context, and all of
those would reload the full AD schema.
The fix is to pre-open the SAM during server startup, before any child
processes are forked. This sets up the global schema context which is
inherited by all connections.
The standard model is still slower at make test than the single model,
but not by nearly as much. I am working on further reducing the gap.
Before this change, the first opener of the sam ldb context would
become the owner of the global schema, then the autofree context got a
reference to the schema. Any subsequent opens of the sam ldb also got
a reference. This meant that the talloc hierarchy was inconsistent
between the first sam ldb open and subsequent opens. With this change
the autofree context becomes the owner of the global schema, and all
ldb contexts get a reference.
These references were triggering the ambiguous talloc_free errors from
the recent talloc changes when the server is run using the 'standard'
process model instead of the 'single' process model. I am aiming to
move the build farm to use the 'standard' process model soon, as part
of an effort to make our test environment better match the real
deployment of Samba4.
The references are not needed as the way that the event context is
used is as the 'top parent', so when the event context is freed then
all of the structures that were taking a reference to the event
context were actually freed as well, thus making the references
redundent.
Recently code was added to match windows semantics of denying the
rename of a directory if there are open files underneath it. This
does partly match windows semantics, but it turns out the rename
should be allowed if the open file handle is for the directory being
renamed, or for a stream on the directory being renamed. This patch
refines the check to better follow these rename semantics.
The existing test was only covering files opened underneath the
directory that was being renamed. It is not uncommon for windows
clients to actually hold a read-only handle to a directory open across
the rename, which it turns out doesn't return NT_STATUS_ACCESS_DENIED.
Additionally, holding a handle open to a stream on the directory is
also allowed.
over the 2G offset on systems which support 64 bit file offsets. This fixes
that case.
On systems with 32 bit offsets, expansion and fcntl locking on these records
will fail anyway. SAMBA already does '#define _FILE_OFFSET_BITS 64' in
config.h (on my 32-bit x86 Linux system at least) to get 64 bit file offsets.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This removes some of the portability changes made to code under
heimdal/
If these are still required, then we will re-add them with code under
heimdal_build/ (so that we can simply 'drop in' future heimdal
releases).
Andrew Bartlett
see bug #6610
The MacOSX SMB client sets the BCC value in SMBwriteX calls to zero
instead of the correct size. Checking against WindowsXP, I've found
that Windows uses the maximum of the computed buffer size and the
given BCC value. I've changed Samba4 to do the same to allow MacOSX to
work.
I've limited this change to non-chained packets to ensure we don't get
the possibility of exploits based on overlapping chained requests
This bug was caused by two things:
1) in the unix ACL mapping, we were not taking into account group
write permssions for the SEC_STD_DELETE flag
2) when a file is created using OVERWRITE mode, a fchmod() would
fail if the user is not the file owner. We resolve that by only
doing the fchmod() if the mapped file attribute does not match the
desired file attribute
