diff options
| author | vorlon <vorlon@alioth.debian.org> | 2007-11-21 17:29:21 +0000 |
|---|---|---|
| committer | vorlon <vorlon@alioth.debian.org> | 2007-11-21 17:29:21 +0000 |
| commit | 58b37572718ed65d1b143f44de16aa5efb512f11 (patch) | |
| tree | 96694e5871586bd21d9b2b91f9a277111ace0812 /docs/htmldocs/Samba3-Developers-Guide/unix-smb.html | |
| parent | f24db2434a26f04e1761c6dbde69d4be999a1cfc (diff) | |
| download | samba-58b37572718ed65d1b143f44de16aa5efb512f11.tar.gz | |
Load samba-3.0.27a into branches/upstream.upstream/3.0.27a
git-svn-id: svn://svn.debian.org/svn/pkg-samba/branches/upstream@1583 fc4039ab-9d04-0410-8cac-899223bdd6b0
Diffstat (limited to 'docs/htmldocs/Samba3-Developers-Guide/unix-smb.html')
| -rw-r--r-- | docs/htmldocs/Samba3-Developers-Guide/unix-smb.html | 202 |
1 files changed, 202 insertions, 0 deletions
diff --git a/docs/htmldocs/Samba3-Developers-Guide/unix-smb.html b/docs/htmldocs/Samba3-Developers-Guide/unix-smb.html new file mode 100644 index 0000000000..d29b8a4eb2 --- /dev/null +++ b/docs/htmldocs/Samba3-Developers-Guide/unix-smb.html @@ -0,0 +1,202 @@ +<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.71.0"><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="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#id315544">Introduction</a></span></dt><dt><span class="sect1"><a href="unix-smb.html#id315562">Usernames</a></span></dt><dt><span class="sect1"><a href="unix-smb.html#id315604">File Ownership</a></span></dt><dt><span class="sect1"><a href="unix-smb.html#id315628">Passwords</a></span></dt><dt><span class="sect1"><a href="unix-smb.html#id315657">Locking</a></span></dt><dt><span class="sect1"><a href="unix-smb.html#id315697">Deny Modes</a></span></dt><dt><span class="sect1"><a href="unix-smb.html#id315716">Trapdoor UIDs</a></span></dt><dt><span class="sect1"><a href="unix-smb.html#id315733">Port numbers</a></span></dt><dt><span class="sect1"><a href="unix-smb.html#id315764">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="id315544"></a>Introduction</h2></div></div></div><p> +This is a short document that describes some of the issues that +confront a SMB implementation on unix, and how Samba copes with +them. They may help people who are looking at unix<->PC +interoperability. +</p><p> +It was written to help out a person who was writing a paper on unix to +PC connectivity. +</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id315562"></a>Usernames</h2></div></div></div><p> +The SMB protocol has only a loose username concept. Early SMB +protocols (such as CORE and COREPLUS) have no username concept at +all. Even in later protocols clients often attempt operations +(particularly printer operations) without first validating a username +on the server. +</p><p> +Unix security is based around username/password pairs. A unix box +should not allow clients to do any substantive operation without some +sort of validation. +</p><p> +The problem mostly manifests itself when the unix server is in "share +level" security mode. This is the default mode as the alternative +"user level" security mode usually forces a client to connect to the +server as the same user for each connected share, which is +inconvenient in many sites. +</p><p> +In "share level" security the client normally gives a username in the +"session setup" protocol, but does not supply an accompanying +password. The client then connects to resources using the "tree +connect" protocol, and supplies a password. The problem is that the +user on the PC types the username and the password in different +contexts, unaware that they need to go together to give access to the +server. The username is normally the one the user typed in when they +"logged onto" the PC (this assumes Windows for Workgroups). The +password is the one they chose when connecting to the disk or printer. +</p><p> +The user often chooses a totally different username for their login as +for the drive connection. Often they also want to access different +drives as different usernames. The unix server needs some way of +divining the correct username to combine with each password. +</p><p> +Samba tries to avoid this problem using several methods. These succeed +in the vast majority of cases. The methods include username maps, the +service%user syntax, the saving of session setup usernames for later +validation and the derivation of the username from the service name +(either directly or via the user= option). +</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id315604"></a>File Ownership</h2></div></div></div><p> +The commonly used SMB protocols have no way of saying "you can't do +that because you don't own the file". They have, in fact, no concept +of file ownership at all. +</p><p> +This brings up all sorts of interesting problems. For example, when +you copy a file to a unix drive, and the file is world writeable but +owned by another user the file will transfer correctly but will +receive the wrong date. This is because the utime() call under unix +only succeeds for the owner of the file, or root, even if the file is +world writeable. For security reasons Samba does all file operations +as the validated user, not root, so the utime() fails. This can stuff +up shared development diectories as programs like "make" will not get +file time comparisons right. +</p><p> +There are several possible solutions to this problem, including +username mapping, and forcing a specific username for particular +shares. +</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id315628"></a>Passwords</h2></div></div></div><p> +Many SMB clients uppercase passwords before sending them. I have no +idea why they do this. Interestingly WfWg uppercases the password only +if the server is running a protocol greater than COREPLUS, so +obviously it isn't just the data entry routines that are to blame. +</p><p> +Unix passwords are case sensitive. So if users use mixed case +passwords they are in trouble. +</p><p> +Samba can try to cope with this by either using the "password level" +option which causes Samba to try the offered password with up to the +specified number of case changes, or by using the "password server" +option which allows Samba to do its validation via another machine +(typically a WinNT server). +</p><p> +Samba supports the password encryption method used by SMB +clients. Note that the use of password encryption in Microsoft +networking leads to password hashes that are "plain text equivalent". +This means that it is *VERY* important to ensure that the Samba +smbpasswd file containing these password hashes is only readable +by the root user. See the documentation ENCRYPTION.txt for more +details. +</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id315657"></a>Locking</h2></div></div></div><p> +Since samba 2.2, samba supports other types of locking as well. This +section is outdated. +</p><p> +The locking calls available under a DOS/Windows environment are much +richer than those available in unix. This means a unix server (like +Samba) choosing to use the standard fcntl() based unix locking calls +to implement SMB locking has to improvise a bit. +</p><p> +One major problem is that dos locks can be in a 32 bit (unsigned) +range. Unix locking calls are 32 bits, but are signed, giving only a 31 +bit range. Unfortunately OLE2 clients use the top bit to select a +locking range used for OLE semaphores. +</p><p> +To work around this problem Samba compresses the 32 bit range into 31 +bits by appropriate bit shifting. This seems to work but is not +ideal. In a future version a separate SMB lockd may be added to cope +with the problem. +</p><p> +It also doesn't help that many unix lockd daemons are very buggy and +crash at the slightest provocation. They normally go mostly unused in +a unix environment because few unix programs use byte range +locking. The stress of huge numbers of lock requests from dos/windows +clients can kill the daemon on some systems. +</p><p> +The second major problem is the "opportunistic locking" requested by +some clients. If a client requests opportunistic locking then it is +asking the server to notify it if anyone else tries to do something on +the same file, at which time the client will say if it is willing to +give up its lock. Unix has no simple way of implementing +opportunistic locking, and currently Samba has no support for it. +</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id315697"></a>Deny Modes</h2></div></div></div><p> +When a SMB client opens a file it asks for a particular "deny mode" to +be placed on the file. These modes (DENY_NONE, DENY_READ, DENY_WRITE, +DENY_ALL, DENY_FCB and DENY_DOS) specify what actions should be +allowed by anyone else who tries to use the file at the same time. If +DENY_READ is placed on the file, for example, then any attempt to open +the file for reading should fail. +</p><p> +Unix has no equivalent notion. To implement this Samba uses either lock +files based on the files inode and placed in a separate lock +directory or a shared memory implementation. The lock file method +is clumsy and consumes processing and file resources, +the shared memory implementation is vastly prefered and is turned on +by default for those systems that support it. +</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id315716"></a>Trapdoor UIDs</h2></div></div></div><p> +A SMB session can run with several uids on the one socket. This +happens when a user connects to two shares with different +usernames. To cope with this the unix server needs to switch uids +within the one process. On some unixes (such as SCO) this is not +possible. This means that on those unixes the client is restricted to +a single uid. +</p><p> +Note that you can also get the "trapdoor uid" message for other +reasons. Please see the FAQ for details. +</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id315733"></a>Port numbers</h2></div></div></div><p> +There is a convention that clients on sockets use high "unprivileged" +port numbers (>1000) and connect to servers on low "privilegedg" port +numbers. This is enforced in Unix as non-root users can't open a +socket for listening on port numbers less than 1000. +</p><p> +Most PC based SMB clients (such as WfWg and WinNT) don't follow this +convention completely. The main culprit is the netbios nameserving on +udp port 137. Name query requests come from a source port of 137. This +is a problem when you combine it with the common firewalling technique +of not allowing incoming packets on low port numbers. This means that +these clients can't query a netbios nameserver on the other side of a +low port based firewall. +</p><p> +The problem is more severe with netbios node status queries. I've +found that WfWg, Win95 and WinNT3.5 all respond to netbios node status +queries on port 137 no matter what the source port was in the +request. This works between machines that are both using port 137, but +it means it's not possible for a unix user to do a node status request +to any of these OSes unless they are running as root. The answer comes +back, but it goes to port 137 which the unix user can't listen +on. Interestingly WinNT3.1 got this right - it sends node status +responses back to the source port in the request. +</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id315764"></a>Protocol Complexity</h2></div></div></div><p> +There are many "protocol levels" in the SMB protocol. It seems that +each time new functionality was added to a Microsoft operating system, +they added the equivalent functions in a new protocol level of the SMB +protocol to "externalise" the new capabilities. +</p><p> +This means the protocol is very "rich", offering many ways of doing +each file operation. This means SMB servers need to be complex and +large. It also means it is very difficult to make them bug free. It is +not just Samba that suffers from this problem, other servers such as +WinNT don't support every variation of every call and it has almost +certainly been a headache for MS developers to support the myriad of +SMB calls that are available. +</p><p> +There are about 65 "top level" operations in the SMB protocol (things +like SMBread and SMBwrite). Some of these include hundreds of +sub-functions (SMBtrans has at least 120 sub-functions, like +DosPrintQAdd and NetSessionEnum). All of them take several options +that can change the way they work. Many take dozens of possible +"information levels" that change the structures that need to be +returned. Samba supports all but 2 of the "top level" functions. It +supports only 8 (so far) of the SMBtrans sub-functions. Even NT +doesn't support them all. +</p><p> +Samba currently supports up to the "NT LM 0.12" protocol, which is the +one preferred by Win95 and WinNT3.5. Luckily this protocol level has a +"capabilities" field which specifies which super-duper new-fangled +options the server suports. This helps to make the implementation of +this protocol level much easier. +</p><p> +There is also a problem with the SMB specications. SMB is a X/Open +spec, but the X/Open book is far from ideal, and fails to cover many +important issues, leaving much to the imagination. Microsoft recently +renamed the SMB protocol CIFS (Common Internet File System) and have +published new specifications. These are far superior to the old +X/Open documents but there are still undocumented calls and features. +This specification is actively being worked on by a CIFS developers +mailing list hosted by Microsft. +</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> |