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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Autobuild-User(master): Andreas Schneider <asn@cryptomilk.org>
Autobuild-Date(master): Mon Oct 28 10:20:35 CET 2013 on sn-devel-104
tevent_req_nomem is to be used in a sequence of async actions where we
have one main request. This is a completely independent loop without one
central tevent_req. tevent_req_nomem is used as a simple way to signal
an out of memory condition to the main request representing the async
sequence. If we don't have such a tevent_req, we need to directly check
for NULL.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
We had a warning about the enum being defined in the parameter list:
warning: ‘enum credentials_obtained’ declared inside parameter list
Signed-off-by: Matthieu Patou <mat@matws.net>
Reviewed-by: Andrew Bartlet <abartlet@samba.org>
Autobuild-User(master): Matthieu Patou <mat@samba.org>
Autobuild-Date(master): Sun Oct 27 02:25:47 CET 2013 on sn-devel-104
Check that FSCTL_SRV_COPYCHUNK_WRITE succeeds when the copy-chunk target
is opened with SEC_RIGHTS_FILE_WRITE only.
Signed-off-by: David Disseldorp <ddiss@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Fri Oct 25 22:48:59 CEST 2013 on sn-devel-104
FSCTL_SRV_COPYCHUNK can only be used when the client has the copy-chunk
target file open with FILE_WRITE_DATA and FILE_READ_DATA.
FSCTL_SRV_COPYCHUNK_WRITE requires only FILE_WRITE_DATA access on the
target, and is therefore suitable for cp --reflink, which opens the
target file O_WRONLY.
Signed-off-by: David Disseldorp <ddiss@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This reverts commit 7b70fa18734d9ceb020fe3e5d4cc0c26cd27a484.
This is a change in behaviour which needs much further investigation
and testing.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: David Disseldorp <ddiss@samba.org>
Autobuild-User(master): David Disseldorp <ddiss@samba.org>
Autobuild-Date(master): Fri Oct 25 14:22:20 CEST 2013 on sn-devel-104
This reverts commit e689b7d51e6ffd848ab10e160dca2c3a03fc750b.
This is a change in behaviour which needs much further investigation
and testing.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: David Disseldorp <ddiss@samba.org>
The LDFLAGS returned by get_python_variables may contain additional library
search paths. These need to be parsed out and placed in LIBPATH to maintain
correct ordering of search paths in the final link flags.
Specifically, appending LDFLAGS directly to LINKFLAGS on my system was causing
/usr/lib to be the first search path specified. This lead to linking against
installed libraries rather than the versions from the current build.
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Fri Oct 25 02:48:35 CEST 2013 on sn-devel-104
When a library or system (like cups) provides an RPATH,
e.g. with -Wl,-R or -Wl,-rpath, this was added by waf
to the LINKFLAGS, wich was later prepended to our RPATH.
But if the path by chance contains an older version of
one of our internal libraries like talloc, this would lead
to linking the too old talloc into our binaries.
This has been observed on, e.g., FreeBSD, but it is a general
problem.
This patch fixes the problem by specially parsing the RPATH
linker options from the pkg-config(, cups-config, ....) output
and putting the paths into the RPATH_<lib> container, which
is then later correctly appended to our internal RPATH.
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Fri Oct 25 00:39:21 CEST 2013 on sn-devel-104
Credentials are no longer used and there were too many arguments to the
constructor
Signed-off-by: Nadezhda Ivanova <nivanova@symas.com>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Restore and backup privileges are not relevant to ldap
access checks, and the TakeOwnership privilege should
grant write_owner right
Signed-off-by: Nadezhda Ivanova <nivanova@symas.com>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: David Disseldorp <ddiss@samba.org>
Autobuild-User(master): David Disseldorp <ddiss@samba.org>
Autobuild-Date(master): Thu Oct 24 16:15:50 CEST 2013 on sn-devel-104
Later on we will have all the oplock/sharemode operations in one routine.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: David Disseldorp <ddiss@samba.org>
This makes the is_stat_open special case in grant_fsp_oplock_type
redundant because in open_file_ntcreate further up we have already set
oplock_request to NO_OPLOCK for stat opens.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: David Disseldorp <ddiss@samba.org>
This avoids the question where it could happen that something else but
fsp->oplock_type might be useful as an argument here.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: David Disseldorp <ddiss@samba.org>
Some lines above we set fsp->oplock_type = e->op_type. I don't see
how this might have changed. This change will unify both callers of
set_file_oplock. In the next step the second parameter to set_file_oplock
will be removed.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: David Disseldorp <ddiss@samba.org>
remove_oplock is a wrapper around release_file_oplock. This streamlines
the exports of oplock.c a bit.
Reason for this patch: In a later patch I will add functionality to
remove_oplock that is required in close_normal_file as well.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: David Disseldorp <ddiss@samba.org>
Fix posix_acl tests to match the change in writing ACLs
with ID_TYPE_BOTH.
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: David Disseldorp <ddiss@samba.org>
When the ID returned is ID_TYPE_BOTH we must *always* add it as both
a user and a group, not just in the owning case. Otherwise DENY
entries are not correctly processed.
Confirmed by the reporter as fixing the problem.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=10196
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: David Disseldorp <ddiss@samba.org>
smbd broke to none twice. Make sure this won't happen again :-)
This used to happen before the MSG_SMB_BREAK_RESPONSE merge. In
process_oplock_break_message we did not call remove_oplock, which would
have prevented this.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Stefan Metzmacher <metze@samba.org>
Autobuild-Date(master): Wed Oct 23 14:06:13 CEST 2013 on sn-devel-104
Now that we transmit the level we want to break to via the msg.op_type
we can unify MSG_SMB_BREAK_REQUEST and MSG_SMB_ASYNC_LEVEL2_BREAK and
thus simplify the code a bit.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
The level we have to break to depend on the breakers create_disposition:
If we overwrite, we have to break to none.
This patch overloads the "op_type" field in the break message we send
across to the smbd holding the oplock with the oplock level we want to
break to. Because it depends on the create_disposition in the breaking
open, only the breaker can make that decision. We might want to use
a different mechanism for this in the future, but for now using the
op_type field seems acceptable to me.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
The level we have to break to depends on the create disposition of the
second opener. If it's overwriting, break to none. If it's not, break
to level2.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
This is what Windows does in this case, we don't survive that. We break
to LEVEL2 here. Fixes and more precise test to follow.
We don't survive this anymore. Re-enable later.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
There's no reason why we should not do this. This has turned into a pure
internal consistency check that should apply fine every time.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
While refactoring find_oplock_types to validate_oplock_types I forgot
that stat opens will end up in locking.tdb. So even with a batch oplock
around we can have more than one entry. This means the consistency check
in validate_oplock_types was wrong and too strict.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Not called right now, because nobody tries multiple sort attributes. But if
someone did, build_response would have looked at the uninitialized controls.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Oct 22 03:28:20 CEST 2013 on sn-devel-104
When listing all ranges with "net idmap get ranges", the database records
of the form "S-1-5-10" --> "GID 100016" were treated here as rangee mapings,
resulting in an faulty printout like this: "RANGE 541346119: S-1-5-10".
This patch fixes this by adding a filter that checks the size of the
value datablob.
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Autobuild-User(master): Andreas Schneider <asn@cryptomilk.org>
Autobuild-Date(master): Mon Oct 21 19:48:40 CEST 2013 on sn-devel-104
We set the socket to nonblocking and don't handle EAGAIN right. We do
a poll anyway, so wait for writability, which should fix this.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=10195
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
