Chapter 1. NetBIOS in a Unix World

Andrew Tridgell

April 1995

Table of Contents

Introduction
Usernames
File Ownership
Passwords
Locking
Deny Modes
Trapdoor UIDs
Port numbers
Protocol Complexity

Introduction

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 @@ -6,7 +6,7 @@ interoperability.

It was written to help out a person who was writing a paper on unix to PC connectivity. -

Usernames

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 @@ -43,7 +43,7 @@ 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). -

File Ownership

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. @@ -61,7 +61,7 @@ file time comparisons right. There are several possible solutions to this problem, including username mapping, and forcing a specific username for particular shares. -

Passwords

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 @@ -83,7 +83,7 @@ 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. -

Locking

Since samba 2.2, samba supports other types of locking as well. This section is outdated.

@@ -114,7 +114,7 @@ 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. -

Deny Modes

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 @@ -128,7 +128,7 @@ 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. -

Trapdoor UIDs

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 @@ -138,7 +138,7 @@ a single uid.

Note that you can also get the "trapdoor uid" message for other reasons. Please see the FAQ for details. -

Port numbers

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 @@ -161,7 +161,7 @@ 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. -

Protocol Complexity

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 -- cgit v1.2.3