docs/textdocs/UNIX-SMB.txt

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