| 1 | <html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 1. NetBIOS in a Unix World</title><link rel="stylesheet" href="../samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.74.0"><link rel="home" href="index.html" title="SAMBA Developers Guide"><link rel="up" href="pt01.html" title="Part I. The protocol"><link rel="prev" href="pt01.html" title="Part I. The protocol"><link rel="next" href="ntdomain.html" title="Chapter 2. 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 1. NetBIOS in a Unix World</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="pt01.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 1. 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#id2499107">Introduction</a></span></dt><dt><span class="sect1"><a href="unix-smb.html#id2499128">Usernames</a></span></dt><dt><span class="sect1"><a href="unix-smb.html#id2499459">File Ownership</a></span></dt><dt><span class="sect1"><a href="unix-smb.html#id2499491">Passwords</a></span></dt><dt><span class="sect1"><a href="unix-smb.html#id2498824">Locking</a></span></dt><dt><span class="sect1"><a href="unix-smb.html#id2498876">Deny Modes</a></span></dt><dt><span class="sect1"><a href="unix-smb.html#id2498908">Trapdoor UIDs</a></span></dt><dt><span class="sect1"><a href="unix-smb.html#id2498929">Port numbers</a></span></dt><dt><span class="sect1"><a href="unix-smb.html#id2549963">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="id2499107"></a>Introduction</h2></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
|
|---|
| 5 | interoperability.
|
|---|
| 6 | </p><p>
|
|---|
| 7 | It was written to help out a person who was writing a paper on unix to
|
|---|
| 8 | PC connectivity.
|
|---|
| 9 | </p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2499128"></a>Usernames</h2></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
|
|---|
| 14 | on the server.
|
|---|
| 15 | </p><p>
|
|---|
| 16 | Unix security is based around username/password pairs. A unix box
|
|---|
| 17 | should not allow clients to do any substantive operation without some
|
|---|
| 18 | sort of validation.
|
|---|
| 19 | </p><p>
|
|---|
| 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.
|
|---|
| 25 | </p><p>
|
|---|
| 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.
|
|---|
| 35 | </p><p>
|
|---|
| 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.
|
|---|
| 40 | </p><p>
|
|---|
| 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="id2499459"></a>File Ownership</h2></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.
|
|---|
| 50 | </p><p>
|
|---|
| 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.
|
|---|
| 60 | </p><p>
|
|---|
| 61 | There are several possible solutions to this problem, including
|
|---|
| 62 | username mapping, and forcing a specific username for particular
|
|---|
| 63 | shares.
|
|---|
| 64 | </p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2499491"></a>Passwords</h2></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.
|
|---|
| 69 | </p><p>
|
|---|
| 70 | Unix passwords are case sensitive. So if users use mixed case
|
|---|
| 71 | passwords they are in trouble.
|
|---|
| 72 | </p><p>
|
|---|
| 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).
|
|---|
| 78 | </p><p>
|
|---|
| 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
|
|---|
| 85 | details.
|
|---|
| 86 | </p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2498824"></a>Locking</h2></div></div></div><p>
|
|---|
| 87 | Since samba 2.2, samba supports other types of locking as well. This
|
|---|
| 88 | section is outdated.
|
|---|
| 89 | </p><p>
|
|---|
| 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.
|
|---|
| 94 | </p><p>
|
|---|
| 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.
|
|---|
| 99 | </p><p>
|
|---|
| 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
|
|---|
| 103 | with the problem.
|
|---|
| 104 | </p><p>
|
|---|
| 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.
|
|---|
| 110 | </p><p>
|
|---|
| 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="id2498876"></a>Deny Modes</h2></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.
|
|---|
| 124 | </p><p>
|
|---|
| 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="id2498908"></a>Trapdoor UIDs</h2></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
|
|---|
| 137 | a single uid.
|
|---|
| 138 | </p><p>
|
|---|
| 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="id2498929"></a>Port numbers</h2></div></div></div><p>
|
|---|
| 142 | There is a convention that clients on sockets use high "unprivileged"
|
|---|
| 143 | port numbers (>1000) and connect to servers on low "privilegedg" 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.
|
|---|
| 146 | </p><p>
|
|---|
| 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.
|
|---|
| 154 | </p><p>
|
|---|
| 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="id2549963"></a>Protocol Complexity</h2></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.
|
|---|
| 169 | </p><p>
|
|---|
| 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.
|
|---|
| 177 | </p><p>
|
|---|
| 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.
|
|---|
| 187 | </p><p>
|
|---|
| 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.
|
|---|
| 193 | </p><p>
|
|---|
| 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="pt01.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">Part I. The protocol </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 2. NT Domain RPC's</td></tr></table></div></body></html>
|
|---|
