← Back to branch summary

~zulcss/samba/server-dailies-3.4

« back to all changes in this revision

Viewing changes to docs-xml/Samba3-Developers-Guide/unix-smb.xml

  • Committer: Chuck Short
  • Date: 2010-09-28 20:38:39 UTC
  • Revision ID: zulcss@ubuntu.com-20100928203839-pgjulytsi9ue63x1
Initial version

Show diffs side-by-side

added added

removed removed

Lines of Context:
docs-xml/Samba3-Developers-Guide/unix-smb.xml
 
1
<?xml version="1.0" encoding="iso-8859-1"?>
 
2
<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
 
3
<chapter id="unix-smb">
 
4
<chapterinfo>
 
5
        <author>
 
6
                <firstname>Andrew</firstname><surname>Tridgell</surname>
 
7
        </author>
 
8
        <pubdate>April 1995</pubdate>
 
9
</chapterinfo>
 
10
 
 
11
<title>NetBIOS in a Unix World</title>
 
12
 
 
13
<sect1>
 
14
<title>Introduction</title>
 
15
<para>
 
16
This is a short document that describes some of the issues that
 
17
confront a SMB implementation on unix, and how Samba copes with
 
18
them. They may help people who are looking at unix&lt;-&gt;PC
 
19
interoperability.
 
20
</para>
 
21
 
 
22
<para>
 
23
It was written to help out a person who was writing a paper on unix to
 
24
PC connectivity.
 
25
</para>
 
26
 
 
27
</sect1>
 
28
 
 
29
<sect1>
 
30
<title>Usernames</title>
 
31
<para>
 
32
The SMB protocol has only a loose username concept. Early SMB
 
33
protocols (such as CORE and COREPLUS) have no username concept at
 
34
all. Even in later protocols clients often attempt operations
 
35
(particularly printer operations) without first validating a username
 
36
on the server.
 
37
</para>
 
38
 
 
39
<para>
 
40
Unix security is based around username/password pairs. A unix box
 
41
should not allow clients to do any substantive operation without some
 
42
sort of validation. 
 
43
</para>
 
44
 
 
45
<para>
 
46
The problem mostly manifests itself when the unix server is in "share
 
47
level" security mode. This is the default mode as the alternative
 
48
"user level" security mode usually forces a client to connect to the
 
49
server as the same user for each connected share, which is
 
50
inconvenient in many sites.
 
51
</para>
 
52
 
 
53
<para>
 
54
In "share level" security the client normally gives a username in the
 
55
"session setup" protocol, but does not supply an accompanying
 
56
password. The client then connects to resources using the "tree
 
57
connect" protocol, and supplies a password. The problem is that the
 
58
user on the PC types the username and the password in different
 
59
contexts, unaware that they need to go together to give access to the
 
60
server. The username is normally the one the user typed in when they
 
61
"logged onto" the PC (this assumes Windows for Workgroups). The
 
62
password is the one they chose when connecting to the disk or printer.
 
63
</para>
 
64
 
 
65
<para>
 
66
The user often chooses a totally different username for their login as
 
67
for the drive connection. Often they also want to access different
 
68
drives as different usernames. The unix server needs some way of
 
69
divining the correct username to combine with each password.
 
70
</para>
 
71
 
 
72
<para>
 
73
Samba tries to avoid this problem using several methods. These succeed
 
74
in the vast majority of cases. The methods include username maps, the
 
75
service%user syntax, the saving of session setup usernames for later
 
76
validation and the derivation of the username from the service name
 
77
(either directly or via the user= option).
 
78
</para>
 
79
 
 
80
</sect1>
 
81
 
 
82
<sect1>
 
83
<title>File Ownership</title>
 
84
 
 
85
<para>
 
86
The commonly used SMB protocols have no way of saying "you can't do
 
87
that because you don't own the file". They have, in fact, no concept
 
88
of file ownership at all.
 
89
</para>
 
90
 
 
91
<para>
 
92
This brings up all sorts of interesting problems. For example, when
 
93
you copy a file to a unix drive, and the file is world writeable but
 
94
owned by another user the file will transfer correctly but will
 
95
receive the wrong date. This is because the utime() call under unix
 
96
only succeeds for the owner of the file, or root, even if the file is
 
97
world writeable. For security reasons Samba does all file operations
 
98
as the validated user, not root, so the utime() fails. This can stuff
 
99
up shared development diectories as programs like "make" will not get
 
100
file time comparisons right.
 
101
</para>
 
102
 
 
103
<para>
 
104
There are several possible solutions to this problem, including
 
105
username mapping, and forcing a specific username for particular
 
106
shares.
 
107
</para>
 
108
 
 
109
</sect1>
 
110
 
 
111
<sect1>
 
112
<title>Passwords</title>
 
113
 
 
114
<para>
 
115
Many SMB clients uppercase passwords before sending them. I have no
 
116
idea why they do this. Interestingly WfWg uppercases the password only
 
117
if the server is running a protocol greater than COREPLUS, so
 
118
obviously it isn't just the data entry routines that are to blame.
 
119
</para>
 
120
 
 
121
<para>
 
122
Unix passwords are case sensitive. So if users use mixed case
 
123
passwords they are in trouble.
 
124
</para>
 
125
 
 
126
<para>
 
127
Samba can try to cope with this by either using the "password level"
 
128
option which causes Samba to try the offered password with up to the
 
129
specified number of case changes, or by using the "password server"
 
130
option which allows Samba to do its validation via another machine
 
131
(typically a WinNT server).
 
132
</para>
 
133
 
 
134
<para>
 
135
Samba supports the password encryption method used by SMB
 
136
clients. Note that the use of password encryption in Microsoft
 
137
networking leads to password hashes that are "plain text equivalent".
 
138
This means that it is *VERY* important to ensure that the Samba
 
139
smbpasswd file containing these password hashes is only readable
 
140
by the root user. See the documentation ENCRYPTION.txt for more
 
141
details.
 
142
</para>
 
143
 
 
144
</sect1>
 
145
 
 
146
<sect1>
 
147
<title>Locking</title>
 
148
<para>
 
149
Since samba 2.2, samba supports other types of locking as well. This 
 
150
section is outdated.
 
151
</para>
 
152
 
 
153
<para>
 
154
The locking calls available under a DOS/Windows environment are much
 
155
richer than those available in unix. This means a unix server (like
 
156
Samba) choosing to use the standard fcntl() based unix locking calls
 
157
to implement SMB locking has to improvise a bit.
 
158
</para>
 
159
 
 
160
<para>
 
161
One major problem is that dos locks can be in a 32 bit (unsigned)
 
162
range. Unix locking calls are 32 bits, but are signed, giving only a 31
 
163
bit range. Unfortunately OLE2 clients use the top bit to select a
 
164
locking range used for OLE semaphores.
 
165
</para>
 
166
 
 
167
<para>
 
168
To work around this problem Samba compresses the 32 bit range into 31
 
169
bits by appropriate bit shifting. This seems to work but is not
 
170
ideal. In a future version a separate SMB lockd may be added to cope
 
171
with the problem.
 
172
</para>
 
173
 
 
174
<para>
 
175
It also doesn't help that many unix lockd daemons are very buggy and
 
176
crash at the slightest provocation. They normally go mostly unused in
 
177
a unix environment because few unix programs use byte range
 
178
locking. The stress of huge numbers of lock requests from dos/windows
 
179
clients can kill the daemon on some systems.
 
180
</para>
 
181
 
 
182
<para>
 
183
The second major problem is the "opportunistic locking" requested by
 
184
some clients. If a client requests opportunistic locking then it is
 
185
asking the server to notify it if anyone else tries to do something on
 
186
the same file, at which time the client will say if it is willing to
 
187
give up its lock. Unix has no simple way of implementing
 
188
opportunistic locking, and currently Samba has no support for it.
 
189
</para>
 
190
 
 
191
</sect1>
 
192
 
 
193
<sect1>
 
194
<title>Deny Modes</title>
 
195
 
 
196
<para>
 
197
When a SMB client opens a file it asks for a particular "deny mode" to
 
198
be placed on the file. These modes (DENY_NONE, DENY_READ, DENY_WRITE,
 
199
DENY_ALL, DENY_FCB and DENY_DOS) specify what actions should be
 
200
allowed by anyone else who tries to use the file at the same time. If
 
201
DENY_READ is placed on the file, for example, then any attempt to open
 
202
the file for reading should fail.
 
203
</para>
 
204
 
 
205
<para>
 
206
Unix has no equivalent notion. To implement this Samba uses either lock
 
207
files based on the files inode and placed in a separate lock
 
208
directory or a shared memory implementation. The lock file method 
 
209
is clumsy and consumes processing and file resources,
 
210
the shared memory implementation is vastly prefered and is turned on
 
211
by default for those systems that support it.
 
212
</para>
 
213
 
 
214
</sect1>
 
215
 
 
216
<sect1>
 
217
<title>Trapdoor UIDs</title>
 
218
<para>
 
219
A SMB session can run with several uids on the one socket. This
 
220
happens when a user connects to two shares with different
 
221
usernames. To cope with this the unix server needs to switch uids
 
222
within the one process. On some unixes (such as SCO) this is not
 
223
possible. This means that on those unixes the client is restricted to
 
224
a single uid.
 
225
</para>
 
226
 
 
227
<para>
 
228
Note that you can also get the "trapdoor uid" message for other
 
229
reasons. Please see the FAQ for details.
 
230
</para>
 
231
 
 
232
</sect1>
 
233
 
 
234
<sect1>
 
235
<title>Port numbers</title>
 
236
<para>
 
237
There is a convention that clients on sockets use high "unprivileged"
 
238
port numbers (>1000) and connect to servers on low "privilegedg" port
 
239
numbers. This is enforced in Unix as non-root users can't open a
 
240
socket for listening on port numbers less than 1000.
 
241
</para>
 
242
 
 
243
<para>
 
244
Most PC based SMB clients (such as WfWg and WinNT) don't follow this
 
245
convention completely. The main culprit is the netbios nameserving on
 
246
udp port 137. Name query requests come from a source port of 137. This
 
247
is a problem when you combine it with the common firewalling technique
 
248
of not allowing incoming packets on low port numbers. This means that
 
249
these clients can't query a netbios nameserver on the other side of a
 
250
low port based firewall.
 
251
</para>
 
252
 
 
253
<para>
 
254
The problem is more severe with netbios node status queries. I've
 
255
found that WfWg, Win95 and WinNT3.5 all respond to netbios node status
 
256
queries on port 137 no matter what the source port was in the
 
257
request. This works between machines that are both using port 137, but
 
258
it means it's not possible for a unix user to do a node status request
 
259
to any of these OSes unless they are running as root. The answer comes
 
260
back, but it goes to port 137 which the unix user can't listen
 
261
on. Interestingly WinNT3.1 got this right - it sends node status
 
262
responses back to the source port in the request.
 
263
</para>
 
264
 
 
265
</sect1>
 
266
 
 
267
<sect1>
 
268
<title>Protocol Complexity</title>
 
269
<para>
 
270
There are many "protocol levels" in the SMB protocol. It seems that
 
271
each time new functionality was added to a Microsoft operating system,
 
272
they added the equivalent functions in a new protocol level of the SMB
 
273
protocol to "externalise" the new capabilities.
 
274
</para>
 
275
 
 
276
<para>
 
277
This means the protocol is very "rich", offering many ways of doing
 
278
each file operation. This means SMB servers need to be complex and
 
279
large. It also means it is very difficult to make them bug free. It is
 
280
not just Samba that suffers from this problem, other servers such as
 
281
WinNT don't support every variation of every call and it has almost
 
282
certainly been a headache for MS developers to support the myriad of
 
283
SMB calls that are available.
 
284
</para>
 
285
 
 
286
<para>
 
287
There are about 65 "top level" operations in the SMB protocol (things
 
288
like SMBread and SMBwrite). Some of these include hundreds of
 
289
sub-functions (SMBtrans has at least 120 sub-functions, like
 
290
DosPrintQAdd and NetSessionEnum). All of them take several options
 
291
that can change the way they work. Many take dozens of possible
 
292
"information levels" that change the structures that need to be
 
293
returned. Samba supports all but 2 of the "top level" functions. It
 
294
supports only 8 (so far) of the SMBtrans sub-functions. Even NT
 
295
doesn't support them all.
 
296
</para>
 
297
 
 
298
<para>
 
299
Samba currently supports up to the "NT LM 0.12" protocol, which is the
 
300
one preferred by Win95 and WinNT3.5. Luckily this protocol level has a
 
301
"capabilities" field which specifies which super-duper new-fangled
 
302
options the server suports. This helps to make the implementation of
 
303
this protocol level much easier.
 
304
</para>
 
305
 
 
306
<para>
 
307
There is also a problem with the SMB specications. SMB is a X/Open
 
308
spec, but the X/Open book is far from ideal, and fails to cover many
 
309
important issues, leaving much to the imagination. Microsoft recently
 
310
renamed the SMB protocol CIFS (Common Internet File System) and have 
 
311
published new specifications. These are far superior to the old 
 
312
X/Open documents but there are still undocumented calls and features. 
 
313
This specification is actively being worked on by a CIFS developers 
 
314
mailing list hosted by Microsft.
 
315
</para>
 
316
</sect1>
 
317
</chapter>
 
318