The basic rule is "avoid static and global data like the plague". What
do I mean by static data? The way to tell if you have static data in a
-file is to use the "size" utility in Linux. For example if we run:
+file is to use the "size" utility in Linux. For example if we run::
size libcli/raw/*.o
-in Samba4 then you get the following:
+in Samba4 then you get the following::
text data bss dec hex filename
2015 0 0 2015 7df libcli/raw/clikrb5.o
good. If there are any non-zero values in data or bss then that
indicates static data and is bad (as a rule of thumb).
-Lets compare that result to the equivalent in Samba3:
+Lets compare that result to the equivalent in Samba3::
text data bss dec hex filename
3978 0 0 3978 f8a libsmb/asn1.o
data is a bug waiting to happen.
Static data is evil as it has the following consequences:
- - it makes code much less likely to be thread-safe
- - it makes code much less likely to be recursion-safe
- - it leads to subtle side effects when the same code is called from
- multiple places
+- it makes code much less likely to be thread-safe
+- it makes code much less likely to be recursion-safe
+- it leads to subtle side effects when the same code is called from
+ multiple places
+- doesn't play well with shared libraries or plugins
Static data is particularly evil in library code (such as our internal
smb and rpc libraries). If you can get rid of all static data in
How to use talloc
-----------------
-Please see the separate document, talloc_guide.txt in this
-directory. You _must_ read this if you want to program in Samba4.
+Please see the separate document, source/lib/talloc/talloc_guide.txt
+You _must_ read this if you want to program in Samba4.
+
Interface Structures
--------------------
In Samba3 many of the core wire structures in the SMB protocol were
never explicitly defined in Samba. Instead, our parse and generation
functions just worked directly with wire buffers. The biggest problem
-with this is that is tied our parse code with out "business logic"
+with this is that is tied our parse code with our "business logic"
much too closely, which meant the code got extremely confusing to
read.
are extremely important differences in the approach that are worth
pointing out.
-In the Samba3 msrpc code we used explicit parse strucrures for all
+In the Samba3 msrpc code we used explicit parse structures for all
msrpc functions. The problem is that we didn't just put all of the
real variables in these structures, we also put in all the artifacts
as well. A good example is the security descriptor strucrure that
-looks like this in Samba3:
+looks like this in Samba3::
-typedef struct security_descriptor_info
-{
- uint16 revision;
- uint16 type;
+ typedef struct security_descriptor_info
+ {
+ uint16 revision;
+ uint16 type;
- uint32 off_owner_sid;
- uint32 off_grp_sid;
- uint32 off_sacl;
- uint32 off_dacl;
+ uint32 off_owner_sid;
+ uint32 off_grp_sid;
+ uint32 off_sacl;
+ uint32 off_dacl;
- SEC_ACL *dacl;
- SEC_ACL *sacl;
- DOM_SID *owner_sid;
- DOM_SID *grp_sid;
-} SEC_DESC;
+ SEC_ACL *dacl;
+ SEC_ACL *sacl;
+ DOM_SID *owner_sid;
+ DOM_SID *grp_sid;
+ } SEC_DESC;
The problem with this structure is all the off_* variables. Those are
not part of the interface, and do not appear in any real descriptions
*NOT* be in the interface structure.
In Samba3 there were unwritten rules about which variables in a
-strucrure a high level caller has to fill in and which ones are filled
+structure a high level caller has to fill in and which ones are filled
in by the marshalling code. In Samba4 those rules are gone, because
the redundent artifact variables are gone. The high level caller just
sets up the real variables and the marshalling code worries about
The first aspect of the async design to look at is the SMB client
library. Lets take a look at the following three functions in
-libcli/raw/rawfile.c:
+libcli/raw/rawfile.c::
-struct cli_request *smb_raw_seek_send(struct cli_tree *tree, struct smb_seek *parms);
-NTSTATUS smb_raw_seek_recv(struct cli_request *req, struct smb_seek *parms);
-NTSTATUS smb_raw_seek(struct cli_tree *tree, struct smb_seek *parms);
+ struct cli_request *smb_raw_seek_send(struct cli_tree *tree, struct smb_seek *parms);
+ NTSTATUS smb_raw_seek_recv(struct cli_request *req, struct smb_seek *parms);
+ NTSTATUS smb_raw_seek(struct cli_tree *tree, struct smb_seek *parms);
Go and read them now then come back.
blocks waiting for the reply.
But what if you want to be called when the reply comes in? Yes, thats
-possible. You can do things like this:
+possible. You can do things like this::
struct cli_request *req;
request asynchronously. The only backend that currently does this is
the CIFS backend, but I hope the other backends will soon do this to.
-To make this work you need to do things like this in the backend:
+To make this work you need to do things like this in the backend::
req->control_flags |= REQ_CONTROL_ASYNC;
each SMB.
As an example go and have a look at reply_getatr_send() and
-reply_getatr() in smbd/reply.c. Read them? Good.
+reply_getatr() in smb_server/reply.c. Read them? Good.
Notice that reply_getatr() sets up the req->async structure to contain
the send function. Thats how the backend gets to do an async reply, it
Notice the union? That's how Samba4 allows a single NTVFS backend
interface to handle the several different ways of doing a write
operation in the SMB protocol. Now lets look at one section of that
-union:
+union::
/* SMBwriteX interface */
struct {
see the "in" and "out" sections? The "in" section is for parameters
that the SMB client sends on the wire as part of the request. The smbd
front end parse code parses the wire request and fills in all those
-parameters. It then calls the NTVFS interface which looks like this:
+parameters. It then calls the NTVFS interface which looks like this::
NTSTATUS (*write)(struct request_context *req, union smb_write *io);
other recognised flags are:
- sign : enable ntlmssp signing
- seal : enable ntlmssp sealing
- connect : enable rpc connect level auth (auth, but no sign or seal)
- validate: enable the NDR validator
- print: enable debugging of the packets
- bigendian: use bigendian RPC
- padcheck: check reply data for non-zero pad bytes
+ sign : enable ntlmssp signing
+ seal : enable ntlmssp sealing
+ spnego : use SPNEGO instead of NTLMSSP authentication
+ krb5 : use KRB5 instead of NTLMSSP authentication
+ connect : enable rpc connect level auth (auth, but no sign or seal)
+ validate : enable the NDR validator
+ print : enable debugging of the packets
+ bigendian : use bigendian RPC
+ padcheck : check reply data for non-zero pad bytes
-For example, these all connect to the samr pipe:
+Here are some examples:
ncacn_np:myserver
ncacn_np:myserver[samr]
ncacn_np:myserver[\pipe\samr]
ncacn_np:myserver[/pipe/samr]
ncacn_np:myserver[samr,sign,print]
+ ncacn_np:myserver[sign,spnego]
ncacn_np:myserver[\pipe\samr,sign,seal,bigendian]
ncacn_np:myserver[/pipe/samr,seal,validate]
ncacn_np:
ncacn_np:[/pipe/samr]
-
ncacn_ip_tcp:myserver
ncacn_ip_tcp:myserver[1024]
- ncacn_ip_tcp:myserver[1024,sign,seal]
+ ncacn_ip_tcp:myserver[sign,seal]
+ ncacn_ip_tcp:myserver[spnego,seal]
IDEA: Maybe extend UNC names like this?
trans2 and other calls
handle servers that don't have the setattre call in torture
add max file coponent length test and max path len test
+ check for alloc failure in all core reply.c and trans2.c code where
+ allocation size depends on client parameter
+
+case-insenstive idea:
+ all filenames on disk lowercase
+ real case in extended attribute
+ keep cache of what dirs are all lowercase
+ when searching for name, don't search if dir is definately all lowercase
+ when creating file, use dnotify to tell if someone else creates at
+ same time
+
+solve del *.* idea:
+ make mangle cache dynamic size
+ fill during a dir scan
+ setup a timer
+ destroy cache after 30 sec
+ destroy if a 2nd dir scan happens on same dir
+
git.samba.org / jelmer / samba4-debian.git / blobdiff