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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Some of the functions in source3/lib/util_sock.c use AI_ADDRCONFIG. On QNX
6.3.0, this macro is defined but, if it's used, getaddrinfo will fail. This
prevents smbd from opening any sockets.
If I undefine AI_ADDRCONFIG on such systems and allow
lib/replace/system/network.h to define it to be 0, this works around the issue.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
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 fixes two issues pointed out by Andrew. It adds a runtime
uwrap_enabled() call that wraps the skips needed for uid emulation. It
also makes the skip in the directory_create_or_exist() function only
change the uid checking code, not the permissions code
This library intercepts seteuid and related calls, and simulates them
in a manner similar to the nss_wrapper and socket_wrapper
libraries. This allows us to enable the vfs_unixuid NTVFS module in
the build farm, which means we are more likely to catch errors in the
token manipulation.
The simulation is not complete, but it is enough for Samba4 for
now. The major areas of incompleteness are:
- no emulation of setreuid, setresuid or saved uids. These would be
needed for use in Samba3
- no emulation of ruid changing. That would also be needed for Samba3
- no attempt to emulate file ownership changing, so code that (for
example) tests whether st.st_uid matches geteuid() needs special
handling
The flags are user-visible, via tdb_get_flags/add_flags/remove_flags.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
This version just wraps the reopen code, so we still re-grab the lock and do
the normal sanity checks.
The reason we do this at all is to avoid global fd limits, see:
http://forums.fedoraforum.org/showthread.php?t=210393
Note also that this whole reopen concept is fundamentally racy: if the parent
goes away before the child calls tdb_reopen_all, the database can be left
without an active lock and another TDB_CLEAR_IF_FIRST opener will clear it.
A fork_with_tdbs() wrapper could use a pipe to solve this, but it's hardly
elegant (what if there are other independent things which have similar needs?).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
This reverts commit e17df483fbedb81aededdef5fbb6ae1d034bc2dd.
tdb_reopen_all also restores the active lock, required for TDB_CLEAR_IF_FIRST.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
54a51839ea65aa788b18fce8de0ae4f9ba63e4e7 "Make tdb transaction lock
recursive (samba version)" was broken: I "cleaned it up" and prevented
it from ever unlocking.
To see the problem:
$ bin/tdbtorture -s 1248142523
tdb_brlock failed (fd=3) at offset 8 rw_type=1 lck_type=14 len=1
tdb_transaction_lock: failed to get transaction lock
tdb_transaction_start failed: Resource deadlock avoided
My testcase relied on the *count* being correct, which it was. Fixing that
now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Michael Adam <obnox@samba.org>
This patch replaces 6ed27edbcd3ba1893636a8072c8d7a621437daf7 and
1a416ff13ca7786f2e8d24c66addf00883e9cb12, which fixed the bug where traversals
inside transactions would release the transaction lock early.
This solution is more general, and solves the more minor symptom that nested
traversals would also release the transaction lock early. (It was also suggestd in
Volker's comment in 6ed27ed).
This patch also applies to ctdb, if the traverse.c part is removed (ctdb's tdb
code never received the previous two fixes).
Tested using the testsuite from ccan (adapted to the samba code). Thanks to
Michael Adam for feedback.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Michael Adam <obnox@samba.org>
move publicly needed structures and functions in the public header.
Stop installing internal headers.
Update the signature and exports files with the new exposed
function.
This is needed to prevent samba3 and samba4 from using an ABI
incompatible system version of talloc
See ongoing discussion on the samba-technical mailing list
These changes follow from the discussions on samba-technical. The
changes are in several parts, and stem from the inherent ambiguity
that was in talloc_free() and talloc_steal() when the pointer that is
being changes has more than one parent, via references.
The changes are:
1) when you call talloc_free() on a pointer with more than one parent
the free will fail, and talloc will log an error to stderr like this:
ERROR: talloc_free with references at some/foo.c:123
reference at other/bar.c:201
reference at other/foobar.c:641
2) Similarly, when you call talloc_steal() on a pointer with more
than one parent, the steal will fail and talloc will log an error to
stderr like this:
ERROR: talloc_steal with references at some/foo.c:123
reference at other/bar.c:201
3) A new function talloc_reparent() has been added to change a parent
in a controlled fashion. You need to supply both the old parent and
the new parent. It handles the case whether either the old parent was
a normal parent or a reference
The use of stderr in the logging is ugly (and potentially dangerous),
and will be removed in a future patch. We'll need to add a debug
registration function to talloc.
The previous code caused memory leaks, and also caused situations
where talloc_free could be called on pointers with multiple parents
The new approach is to have two functions:
py_talloc_import : steals the pointer, so it becomes wholly owned by
the python object
py_talloc_reference: uses a reference, so it is owned by both python
and C
I some cases the pointer value of tevent_context is the same again,
if we do something like:
ev1 = tevent_context_init();
...
fde = tevent_add_fd(ev1, fd, TEVENT_FD_READ...);
...
talloc_free(ev1);
...
ev2 = tevent_context_init();
if (ev1 == ev2) {
/* this can happen! */
}
if (tevent_fd_get_flags(fde) == 0) {
/* this is always true */
}
But the "talloc_free(ev1)" will set fde->event_ctx to NULL
and tevent_fd_get_flags() will always return 0.
metze
By adding a new common setup_logging_stdout() API, we no longer need to abuse the ABI compatability between the different setup_logging() calls in Samba3 and Samba4's DEBUG() subsystems.
The revert of 49a6d757b4d944cd22c91b2838beb83f04fbe1e9 works with this
to fix bug 6211.
Andrew Bartlett
The problem is that the enum was previously a 'rachet', that is, it
would only reset to a level higher than it was previouly set to.
Changing the order broke file-based logging for our production sites.
This reverts commit 49a6d757b4d944cd22c91b2838beb83f04fbe1e9.
This keeps the restriction for stream sockets (where the caller will
retry), without creating problems on datagram sockets (CLDAP is not
defined, as far as I know, across multiple UDP packets).
The commit adding this restriction was
47b106c0ae8b91c9cccfc21bf8e4e416b1abfd5d
Andrew Bartlett
