mirror of
https://github.com/samba-team/samba.git
synced 2025-01-27 14:04:05 +03:00
Remove more obsolete documents
(This used to be commit 60446ad6033f6f9179ac2566f670d04ff8b662c2)
This commit is contained in:
Jelmer Vernooij
parent
38cc0a1b81
commit
f338cf5a83
@ -1,46 +0,0 @@
|
||||
Contributor: Unknown
|
||||
Date: Updated April 19th 1999.
|
||||
Status: Current
|
||||
|
||||
Subject: NOTE ABOUT PASSWORDS
|
||||
=============================================================================
|
||||
|
||||
Unix systems use a wide variety of methods for checking the validity
|
||||
of a password. This is primarily controlled with the Makefile defines
|
||||
mentioned in the Makefile.
|
||||
|
||||
Also note that some clients (notably WfWg) uppercase the password
|
||||
before sending it. The server tries the password as it receives it and
|
||||
also after lowercasing it.
|
||||
|
||||
The Samba server can also be configured to try different
|
||||
upper/lowercase combinations. This is controlled by the [global]
|
||||
parameter "password level". A level of N means to try all combinations
|
||||
up to N uppercase characters in the password. A high value can chew a
|
||||
fair bit of CPU time and can lower the security of your system. Do not
|
||||
use this options unless you really need it - the time taken for
|
||||
password checking can become so high that clients time out.
|
||||
|
||||
If you do use the "password level" option then you might like to use
|
||||
-DUFC_CRYPT in your Makefile. On some machine this makes password
|
||||
checking _much_ faster. This is also useful if you use the @group
|
||||
syntax in the user= option.
|
||||
|
||||
If your site uses AFS (the Andrew File System), you can use the AFS section
|
||||
in the Makefile. This will first attempt to authenticate a username and
|
||||
password to AFS. If that succeeds, then the associated AFS rights will be
|
||||
granted. Otherwise, the password checking routine falls back to whatever
|
||||
Unix password checking method you are using. Note that the AFS code is
|
||||
only written and tested for AFS 3.3 and later.
|
||||
|
||||
|
||||
SECURITY = SERVER or DOMAIN
|
||||
===========================
|
||||
|
||||
Samba can use a remote server to do its username/password
|
||||
validation. This allows you to have one central machine (for example a
|
||||
NT box) control the passwords for the Unix box.
|
||||
|
||||
See the section on "security =" in smb.conf(5) for details.
|
||||
|
||||
|
||||
@ -1,93 +0,0 @@
|
||||
Contributor: Andrew Tridgell <samba@samba.org>
|
||||
Date: Old
|
||||
Status: Questionable
|
||||
|
||||
Subject: How to trace samba system calls for debugging purposes
|
||||
=============================================================================
|
||||
|
||||
This file describes how to do a system call trace on Samba to work out
|
||||
what its doing wrong. This is not for the faint of heart, but if you
|
||||
are reading this then you are probably desperate.
|
||||
|
||||
Actually its not as bad as the the above makes it sound, just don't
|
||||
expect the output to be very pretty :-)
|
||||
|
||||
Ok, down to business. One of the big advantages of unix systems is
|
||||
that they nearly all come with a system trace utility that allows you
|
||||
to monitor all system calls that a program is making. This is
|
||||
extremely using for debugging and also helps when trying to work out
|
||||
why something is slower than you expect. You can use system tracing
|
||||
without any special compilation options.
|
||||
|
||||
The system trace utility is called different things on different
|
||||
systems. On Linux systems its called strace. Under SunOS 4 its called
|
||||
trace. Under SVR4 style systems (including solaris) its called
|
||||
truss. Under many BSD systems its called ktrace.
|
||||
|
||||
The first thing you should do is read the man page for your native
|
||||
system call tracer. In the discussion below I'll assume its called
|
||||
strace as strace is the only portable system tracer (its available for
|
||||
free for many unix types) and its also got some of the nicest
|
||||
features.
|
||||
|
||||
Next, try using strace on some simple commands. For example, "strace
|
||||
ls" or "strace echo hello".
|
||||
|
||||
You'll notice that it produces a LOT of output. It is showing you the
|
||||
arguments to every system call that the program makes and the
|
||||
result. Very little happens in a program without a system call so you
|
||||
get lots of output. You'll also find that it produces a lot of
|
||||
"preamble" stuff showing the loading of shared libraries etc. Ignore
|
||||
this (unless its going wrong!)
|
||||
|
||||
For example, the only line that really matters in the "strace echo
|
||||
hello" output is:
|
||||
|
||||
write(1, "hello\n", 6) = 6
|
||||
|
||||
all the rest is just setting up to run the program.
|
||||
|
||||
Ok, now you're famialiar with strace. To use it on Samba you need to
|
||||
strace the running smbd daemon. The way I tend ot use it is to first
|
||||
login from my Windows PC to the Samba server, then use smbstatus to
|
||||
find which process ID that client is attached to, then as root I do
|
||||
"strace -p PID" to attach to that process. I normally redirect the
|
||||
stderr output from this command to a file for later perusal. For
|
||||
example, if I'm using a csh style shell:
|
||||
|
||||
strace -f -p 3872 >& strace.out
|
||||
|
||||
or with a sh style shell:
|
||||
|
||||
strace -f -p 3872 > strace.out 2>&1
|
||||
|
||||
Note the "-f" option. This is only available on some systems, and
|
||||
allows you to trace not just the current process, but any children it
|
||||
forks. This is great for finding printing problems caused by the
|
||||
"print command" being wrong.
|
||||
|
||||
Once you are attached you then can do whatever it is on the client
|
||||
that is causing problems and you will capture all the system calls
|
||||
that smbd makes.
|
||||
|
||||
So how do you interpret the results? Generally I search through the
|
||||
output for strings that I know will appear when the problem
|
||||
happens. For example, if I am having touble with permissions on a file
|
||||
I would search for that files name in the strace output and look at
|
||||
the surrounding lines. Another trick is to match up file descriptor
|
||||
numbers and "follow" what happens to an open file until it is closed.
|
||||
|
||||
Beyond this you will have to use your initiative. To give you an idea
|
||||
of wehat you are looking for here is a piece of strace output that
|
||||
shows that /dev/null is not world writeable, which causes printing to
|
||||
fail with Samba:
|
||||
|
||||
[pid 28268] open("/dev/null", O_RDWR) = -1 EACCES (Permission denied)
|
||||
[pid 28268] open("/dev/null", O_WRONLY) = -1 EACCES (Permission denied)
|
||||
|
||||
the process is trying to first open /dev/null read-write then
|
||||
read-only. Both fail. This means /dev/null has incorrect permissions.
|
||||
|
||||
Have fun!
|
||||
|
||||
(please send updates/fixes to this file to samba@samba.org)
|
||||
@ -1,231 +0,0 @@
|
||||
Contributor: Andrew Tridgell <samba@samba.org>
|
||||
Date: April 1995
|
||||
|
||||
Subject: Discussion of NetBIOS in a Unix World
|
||||
============================================================================
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
(particularly printer operations) without first validating a username
|
||||
on the server.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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).
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
obviously it isn't just the data entry routines that are to blame.
|
||||
|
||||
Unix passwords are case sensitive. So if users use mixed case
|
||||
passwords they are in trouble.
|
||||
|
||||
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).
|
||||
|
||||
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.
|
||||
|
||||
|
||||
Locking
|
||||
=======
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
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.
|
||||
|
||||
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 "unprivilaged"
|
||||
port numbers (>1000) and connect to servers on low "privilaged" port
|
||||
numbers. This is enforced in Unix as non-root users can't open a
|
||||
socket for listening on port numbers less than 1000.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
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
|
||||
protocol to "externalise" the new capabilities.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
Loading…
x
Reference in New Issue
Block a user