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