Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
This means we use just one constant for this file attribute.
Andrew Bartlett
|
|
Autobuild-User: Jeremy Allison <jra@samba.org>
Autobuild-Date: Sat Apr 16 02:15:38 CEST 2011 on sn-devel-104
|
|
Guenther
|
|
Guenther
|
|
Will later become part of locking.h
Guenther
|
|
Guenther
|
|
Pair-Programmed-With: Michael Adam <obnox@samba.org>
metze
Autobuild-User: Stefan Metzmacher <metze@samba.org>
Autobuild-Date: Fri Mar 18 13:00:51 CET 2011 on sn-devel-104
|
|
caller wants read_only
This triggered deadlocks in the cluster case of brl_get_locks_readonly().
Pair-Programmed-With: Michael Adam <obnox@samba.org>
metze
|
|
this value when searching for specific share mode entries.
Jeremy.
Autobuild-User: Jeremy Allison <jra@samba.org>
Autobuild-Date: Thu Mar 17 19:59:51 CET 2011 on sn-devel-104
|
|
Guenther
|
|
|
|
Autobuild-User: Jeremy Allison <jra@samba.org>
Autobuild-Date: Wed Jan 26 00:46:28 CET 2011 on sn-devel-104
|
|
Do this by keeping a linked list of delete on close tokens, one for
each filename that identifies a path to the dev/inode. Use the
jenkins hash of the pathname to identify the correct token.
|
|
Will be used when we store more than one delete on close token.
|
|
to identify a specific path).
|
|
This will reduce the noise from merges of the rest of the
libcli/security code, without this commit changing what code
is actually used.
This includes (along with other security headers) dom_sid.h and
security_token.h
Andrew Bartlett
Autobuild-User: Andrew Bartlett <abartlet@samba.org>
Autobuild-Date: Tue Oct 12 05:54:10 UTC 2010 on sn-devel-104
|
|
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.
|
|
Guenther
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
smblctx in our locking code. 2). Widens smblctx to 64-bits internally. Preparing to use the SMB2 handle as the locking context.
Jeremy.
|
|
next :-).
Jeremy.
|
|
Jeremy.
|
|
Satisfies SMB and SMB2.
Jeremy.
|
|
This shrinks include/includes.h.gch by the size of 7 MB and reduces build time
as follows:
ccache build w/o patch
real 4m21.529s
ccache build with patch
real 3m6.402s
pch build w/o patch
real 4m26.318s
pch build with patch
real 3m6.932s
Guenther
|
|
|
|
This will allow us to share logic much easier between SMB1 and SMB2
servers.
Jeremy
|
|
it should already be pointing to a token with uid == 0.
Jeremy.
|
|
struct current_user current_user;"."
As requested by Volker, split this into smaller commits.
Jeremy.
|
|
Use accessor functions to get to this value. Tidies up much of
the user context code. Volker, please look at the changes in smbd/uid.c
to familiarize yourself with these changes as I think they make the
logic in there cleaner.
Cause smbd/posix_acls.c code to look at current user context, not
stored context on the conn struct - allows correct use of these
function calls under a become_root()/unbecome_root() pair.
Jeremy.
|
|
When a samba server process dies hard, it has no chance to clean up its entries
in locking.tdb, brlock.tdb, connections.tdb and sessionid.tdb.
For locking.tdb and brlock.tdb Samba is robust by checking every time we read
an entry from the database if the corresponding process still exists. If it
does not exist anymore, the entry is deleted. This is not 100% failsafe though:
On systems with a limited PID space there is a non-zero chance that between the
smbd's death and the fresh access, the PID is recycled by another long-running
process. This renders all files that had been locked by the killed smbd
potentially unusable until the new process also dies.
This patch is supposed to fix the problem the following way: Every process ID
in every database is augmented by a random 64-bit number that is stored in a
serverid.tdb. Whenever we need to check if a process still exists we know its
PID and the 64-bit number. We look up the PID in serverid.tdb and compare the
64-bit number. If it's the same, the process still is a valid smbd holding the
lock. If it is different, a new smbd has taken over.
I believe this is safe against an smbd that has died hard and the PID has been
taken over by a non-samba process. This process would not have registered
itself with a fresh 64-bit number in serverid.tdb, so the old one still exists
in serverid.tdb. We protect against this case by the parent smbd taking care of
deregistering PIDs from serverid.tdb and the fact that serverid.tdb is
CLEAR_IF_FIRST.
CLEAR_IF_FIRST does not work in a cluster, so the automatic cleanup does not
work when all smbds are restarted. For this, "net serverid wipe" has to be run
before smbd starts up. As a convenience, "net serverid wipedbs" also cleans up
sessionid.tdb and connections.tdb.
While there, this also cleans up overloading connections.tdb with all the
process entries just for messaging_send_all().
Volker
|
|
|
|
(cherry picked from commit 6c6df527e14514027cbcaa6deac25adf04363926)
|
|
rights fails even if the delete right is set on the object.
Final fix for the vfs_acl_xattr and vfs_acl_tdb code.
Ensure we can delete a file even if the underlying POSIX
permissions don't allow it, if the Windows permissions do.
Jeremy.
|
|
Implement the win7 NT_STATUS_INVALID_LOCK_RANGE.
Make smbd behave as Windows does in canceling locks.
Jeremy.
|
|
can_set_delete_on_close() is correctly called before any setting
of the disposition bit (clean up the do_unlink() call).
Jeremy.
|
|
We are assigning the complete structure now (we used to assign individual
fields), so this is obsolete.
|
|
For a netbench run this gains around 2% user-space CPU, fetching a 100MB file
takes around 4% less.
|
|
smbd just crashed on me: In a debug message I called a routine preparing a
string that itself used debug_ctx. The outer routine also used it after the
inner routine had returned. It was still referencing the talloc context
that the outer debug_ctx() had given us, which the inner DEBUG had already
freed.
|
|
Re-write core of POSIX locking logic.
Jeremy.
|
|
This might help finding why bug 6518 happens
|