1
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter�2.�NetBIOS in a Unix World</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.64.1"><link rel="home" href="index.html" title="SAMBA Developers Guide"><link rel="up" href="pt01.html" title="Part�I.�The protocol"><link rel="previous" href="netbios.html" title="Chapter�1.�Definition of NetBIOS Protocol and Name Resolution Modes"><link rel="next" href="ntdomain.html" title="Chapter�3.�NT Domain RPC's"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter�2.�NetBIOS in a Unix World</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="netbios.html">Prev</a>�</td><th width="60%" align="center">Part�I.�The protocol</th><td width="20%" align="right">�<a accesskey="n" href="ntdomain.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="unix-smb"></a>Chapter�2.�NetBIOS in a Unix World</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Andrew</span> <span class="surname">Tridgell</span></h3></div></div><div><p class="pubdate">April 1995</p></div></div><div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="unix-smb.html#id2444446">Introduction</a></span></dt><dt><span class="sect1"><a href="unix-smb.html#id2444467">Usernames</a></span></dt><dt><span class="sect1"><a href="unix-smb.html#id2444526">File Ownership</a></span></dt><dt><span class="sect1"><a href="unix-smb.html#id2444557">Passwords</a></span></dt><dt><span class="sect1"><a href="unix-smb.html#id2444595">Locking</a></span></dt><dt><span class="sect1"><a href="unix-smb.html#id2444647">Deny Modes</a></span></dt><dt><span class="sect1"><a href="unix-smb.html#id2506485">Trapdoor UIDs</a></span></dt><dt><span class="sect1"><a href="unix-smb.html#id2506506">Port numbers</a></span></dt><dt><span class="sect1"><a href="unix-smb.html#id2506551">Protocol Complexity</a></span></dt></dl></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2444446"></a>Introduction</h2></div></div><div></div></div><p>
2
This is a short document that describes some of the issues that
3
confront a SMB implementation on unix, and how Samba copes with
4
them. They may help people who are looking at unix<->PC
7
It was written to help out a person who was writing a paper on unix to
9
</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2444467"></a>Usernames</h2></div></div><div></div></div><p>
10
The SMB protocol has only a loose username concept. Early SMB
11
protocols (such as CORE and COREPLUS) have no username concept at
12
all. Even in later protocols clients often attempt operations
13
(particularly printer operations) without first validating a username
16
Unix security is based around username/password pairs. A unix box
17
should not allow clients to do any substantive operation without some
20
The problem mostly manifests itself when the unix server is in "share
21
level" security mode. This is the default mode as the alternative
22
"user level" security mode usually forces a client to connect to the
23
server as the same user for each connected share, which is
24
inconvenient in many sites.
26
In "share level" security the client normally gives a username in the
27
"session setup" protocol, but does not supply an accompanying
28
password. The client then connects to resources using the "tree
29
connect" protocol, and supplies a password. The problem is that the
30
user on the PC types the username and the password in different
31
contexts, unaware that they need to go together to give access to the
32
server. The username is normally the one the user typed in when they
33
"logged onto" the PC (this assumes Windows for Workgroups). The
34
password is the one they chose when connecting to the disk or printer.
36
The user often chooses a totally different username for their login as
37
for the drive connection. Often they also want to access different
38
drives as different usernames. The unix server needs some way of
39
divining the correct username to combine with each password.
41
Samba tries to avoid this problem using several methods. These succeed
42
in the vast majority of cases. The methods include username maps, the
43
service%user syntax, the saving of session setup usernames for later
44
validation and the derivation of the username from the service name
45
(either directly or via the user= option).
46
</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2444526"></a>File Ownership</h2></div></div><div></div></div><p>
47
The commonly used SMB protocols have no way of saying "you can't do
48
that because you don't own the file". They have, in fact, no concept
49
of file ownership at all.
51
This brings up all sorts of interesting problems. For example, when
52
you copy a file to a unix drive, and the file is world writeable but
53
owned by another user the file will transfer correctly but will
54
receive the wrong date. This is because the utime() call under unix
55
only succeeds for the owner of the file, or root, even if the file is
56
world writeable. For security reasons Samba does all file operations
57
as the validated user, not root, so the utime() fails. This can stuff
58
up shared development diectories as programs like "make" will not get
59
file time comparisons right.
61
There are several possible solutions to this problem, including
62
username mapping, and forcing a specific username for particular
64
</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2444557"></a>Passwords</h2></div></div><div></div></div><p>
65
Many SMB clients uppercase passwords before sending them. I have no
66
idea why they do this. Interestingly WfWg uppercases the password only
67
if the server is running a protocol greater than COREPLUS, so
68
obviously it isn't just the data entry routines that are to blame.
70
Unix passwords are case sensitive. So if users use mixed case
71
passwords they are in trouble.
73
Samba can try to cope with this by either using the "password level"
74
option which causes Samba to try the offered password with up to the
75
specified number of case changes, or by using the "password server"
76
option which allows Samba to do its validation via another machine
77
(typically a WinNT server).
79
Samba supports the password encryption method used by SMB
80
clients. Note that the use of password encryption in Microsoft
81
networking leads to password hashes that are "plain text equivalent".
82
This means that it is *VERY* important to ensure that the Samba
83
smbpasswd file containing these password hashes is only readable
84
by the root user. See the documentation ENCRYPTION.txt for more
86
</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2444595"></a>Locking</h2></div></div><div></div></div><p>
87
Since samba 2.2, samba supports other types of locking as well. This
90
The locking calls available under a DOS/Windows environment are much
91
richer than those available in unix. This means a unix server (like
92
Samba) choosing to use the standard fcntl() based unix locking calls
93
to implement SMB locking has to improvise a bit.
95
One major problem is that dos locks can be in a 32 bit (unsigned)
96
range. Unix locking calls are 32 bits, but are signed, giving only a 31
97
bit range. Unfortunately OLE2 clients use the top bit to select a
98
locking range used for OLE semaphores.
100
To work around this problem Samba compresses the 32 bit range into 31
101
bits by appropriate bit shifting. This seems to work but is not
102
ideal. In a future version a separate SMB lockd may be added to cope
105
It also doesn't help that many unix lockd daemons are very buggy and
106
crash at the slightest provocation. They normally go mostly unused in
107
a unix environment because few unix programs use byte range
108
locking. The stress of huge numbers of lock requests from dos/windows
109
clients can kill the daemon on some systems.
111
The second major problem is the "opportunistic locking" requested by
112
some clients. If a client requests opportunistic locking then it is
113
asking the server to notify it if anyone else tries to do something on
114
the same file, at which time the client will say if it is willing to
115
give up its lock. Unix has no simple way of implementing
116
opportunistic locking, and currently Samba has no support for it.
117
</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2444647"></a>Deny Modes</h2></div></div><div></div></div><p>
118
When a SMB client opens a file it asks for a particular "deny mode" to
119
be placed on the file. These modes (DENY_NONE, DENY_READ, DENY_WRITE,
120
DENY_ALL, DENY_FCB and DENY_DOS) specify what actions should be
121
allowed by anyone else who tries to use the file at the same time. If
122
DENY_READ is placed on the file, for example, then any attempt to open
123
the file for reading should fail.
125
Unix has no equivalent notion. To implement this Samba uses either lock
126
files based on the files inode and placed in a separate lock
127
directory or a shared memory implementation. The lock file method
128
is clumsy and consumes processing and file resources,
129
the shared memory implementation is vastly prefered and is turned on
130
by default for those systems that support it.
131
</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2506485"></a>Trapdoor UIDs</h2></div></div><div></div></div><p>
132
A SMB session can run with several uids on the one socket. This
133
happens when a user connects to two shares with different
134
usernames. To cope with this the unix server needs to switch uids
135
within the one process. On some unixes (such as SCO) this is not
136
possible. This means that on those unixes the client is restricted to
139
Note that you can also get the "trapdoor uid" message for other
140
reasons. Please see the FAQ for details.
141
</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2506506"></a>Port numbers</h2></div></div><div></div></div><p>
142
There is a convention that clients on sockets use high "unprivilaged"
143
port numbers (>1000) and connect to servers on low "privilaged" port
144
numbers. This is enforced in Unix as non-root users can't open a
145
socket for listening on port numbers less than 1000.
147
Most PC based SMB clients (such as WfWg and WinNT) don't follow this
148
convention completely. The main culprit is the netbios nameserving on
149
udp port 137. Name query requests come from a source port of 137. This
150
is a problem when you combine it with the common firewalling technique
151
of not allowing incoming packets on low port numbers. This means that
152
these clients can't query a netbios nameserver on the other side of a
153
low port based firewall.
155
The problem is more severe with netbios node status queries. I've
156
found that WfWg, Win95 and WinNT3.5 all respond to netbios node status
157
queries on port 137 no matter what the source port was in the
158
request. This works between machines that are both using port 137, but
159
it means it's not possible for a unix user to do a node status request
160
to any of these OSes unless they are running as root. The answer comes
161
back, but it goes to port 137 which the unix user can't listen
162
on. Interestingly WinNT3.1 got this right - it sends node status
163
responses back to the source port in the request.
164
</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2506551"></a>Protocol Complexity</h2></div></div><div></div></div><p>
165
There are many "protocol levels" in the SMB protocol. It seems that
166
each time new functionality was added to a Microsoft operating system,
167
they added the equivalent functions in a new protocol level of the SMB
168
protocol to "externalise" the new capabilities.
170
This means the protocol is very "rich", offering many ways of doing
171
each file operation. This means SMB servers need to be complex and
172
large. It also means it is very difficult to make them bug free. It is
173
not just Samba that suffers from this problem, other servers such as
174
WinNT don't support every variation of every call and it has almost
175
certainly been a headache for MS developers to support the myriad of
176
SMB calls that are available.
178
There are about 65 "top level" operations in the SMB protocol (things
179
like SMBread and SMBwrite). Some of these include hundreds of
180
sub-functions (SMBtrans has at least 120 sub-functions, like
181
DosPrintQAdd and NetSessionEnum). All of them take several options
182
that can change the way they work. Many take dozens of possible
183
"information levels" that change the structures that need to be
184
returned. Samba supports all but 2 of the "top level" functions. It
185
supports only 8 (so far) of the SMBtrans sub-functions. Even NT
186
doesn't support them all.
188
Samba currently supports up to the "NT LM 0.12" protocol, which is the
189
one preferred by Win95 and WinNT3.5. Luckily this protocol level has a
190
"capabilities" field which specifies which super-duper new-fangled
191
options the server suports. This helps to make the implementation of
192
this protocol level much easier.
194
There is also a problem with the SMB specications. SMB is a X/Open
195
spec, but the X/Open book is far from ideal, and fails to cover many
196
important issues, leaving much to the imagination. Microsoft recently
197
renamed the SMB protocol CIFS (Common Internet File System) and have
198
published new specifications. These are far superior to the old
199
X/Open documents but there are still undocumented calls and features.
200
This specification is actively being worked on by a CIFS developers
201
mailing list hosted by Microsft.
202
</p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="netbios.html">Prev</a>�</td><td width="20%" align="center"><a accesskey="u" href="pt01.html">Up</a></td><td width="40%" align="right">�<a accesskey="n" href="ntdomain.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter�1.�Definition of NetBIOS Protocol and Name Resolution Modes�</td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top">�Chapter�3.�NT Domain RPC's</td></tr></table></div></body></html>
added
removed
docs/htmldocs/Samba-Developers-Guide/unix-smb.html
