docs/textdocs/UNIX-SMB.txt

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