Samba Traffic #24 For 30 Jun 2000

A small pile of e-mail (thanks, people!) tells me that my recent absence from Kernel Cousin Samba has not gone entirely unnoticed. For the curious, I have had a month or so with very little time for activities such as editing this newsletter. As I don't foresee the situation improving substantially, I am cutting back to a less frequent publishing schedule, tentatively twice a month. I am not planning any substantial changes to coverage or style. If anyone is interested in taking up the alternate weeks, please contact me.

This issue was challenging, for there was much to cover. The general direction of Samba development, while constantly in flux, seems to have been more so of late. Luke has all but dropped Samba-TNG in favor of interface-driven server code, which he has been developing more or less from scratch; Elrond has taken over as primary contributor to Samba-TNG. Jeremy and other troops continue to pound away at what will become the next stable Samba release, an effort which has greatly outgrown the modest bug-fix charter upon which the 2.0 branch was founded. Tim has been overhauling winbind, which promises to be a very useful product for a lot of people with or without the rest of Samba, once it hits prime time. Tridge? He continues to fix memory leaks, hack on miscellaneous HEAD code, and work on his AWK-based interface parser.

(One minor change in this issue: for various reasons, I am now hyperlinking to a non-samba.org mail archive site. The biggest reason is that I just love MHonArc, the software used on sites like kernelnotes.org and debian.org. I find MHonArc-generated archives much better threaded and more navigable than any alternative I've seen to date, including Hypermail. If you prefer Hypermail, as it seems some people do, then We Apologize For The Inconvenience.)

There were 239 different contributors. 84 posted more than once. 50 posted last week too.

Pieter Grimmerink knew this was offtopic, but was very curious about allowing a single Windows NT computer to be a member of multiple domains at once. He has a laptop and is currently forced to run Windows98 on it, since Windows98 is more flexible in this regard. (Since Windows does not actually join a domain, there is little problem moving from one to another.)

Several partial solutions presented themselves. Jens Skripczynski said that Pieter should be able to join multiple domains, one after another, with a reboot in between, and they should all show up in the logon dialog afterwards. But Paul Collins replied, "I was under the impression that the only time more than two domains are listed in the "Domain" list on the logon screen is when the domain your machine is currently a member of trusts other domains. I don't see how a machine could be a member of two unrelated domains and still let you log on to both, since the only DOMAIN\Domain Users global group in WKS\Users would be that belonging to the domain you most recently joined."

Tim Cole suggested, "Alternatively, you may be able to take advantage of trust relationships between the domains." Unfortunately, Pieter's domains were unrelated to each other.

Elrond suggested: "If you have NT4 Server, you should be able to create your own domain and then create a trust-relationship to both domains. That is:
localdomain trusts domain-a
localdomain trusts domain-b
Would that work?" I noted that while this should work, the cost of an NT Server license had to be considered.

Luke Leighton's idea: "dual installations, waste a bit of disk space, what the heck :)"

This thread started out with Jerry Carter asking about how important it was to keep the user-RID mapping consistent through a Samba upgrade:

The issue the allocation of user RID's in the LDAP entries. Under the scheme devised for SAMBA_TNG (i'm talking about the older LDAP schema), RID's are generated automatically and in a monotonically increasing order (like NT). However, this will make it very difficult to migrate from smbpasswd to LDAP in a Samba controlled NT domain.

Why you ask? :-)

Changing the user RID will break existing profiles. So how do we get around this? By setting the RID to be the same. I have some perl scripts that will transder an smbpasswd into an LDAP tree while keeping this existing user RID (as defined by the algorithms currently coded in smbd).

However, this migration strategy breaks the incremental RID allocation scheme use by the LDAP passwd backend.

Finally, my point. I would like to allocate the RID's based upon the samba uid <-> RID mapping function implemented in the main branch.

What say people to this?

Luke noted that since the existing mapping scheme was insufficient to hold all necessary information, there was not much choice in the matter. Besides, "there is no official support for pdc functionality. therefore, technically, there is a reason why we cannot support pre-existing uid <-> rid schemes based on smbpasswd, and officially there is a reason why we do not support any pre-existing schemes. therefore, there's no issue." Jerry didn't like this answer; he felt backward compatibility was important, and liked the idea of being able to map UIDs to RIDs and back, deterministically.

Inge-Håvard Hunstad noted that he had had trouble with profile permissions in this scenario, but continued, "I'm not sure though, why I can change the rid of a NT-machine in the domain and still have no problem. I even changed the grouprid of the machine and still no problem. So if there are some Samba or NT gurus out there that will comment on this I would be very happy:-)" Jerry replied, "The machine RID doesn't really mater i think as it is never used in an ACL. WHen a machine joins a domain, it remembers the domain SID from the PDC. If this changes, the client machine will need to rejoin the domain. The machine also has a local SID as you know. I don't personally know of any instance where the domain RID of a machine is used."

At this point Luke changed the subject a little: "we're probably going to drop private/smbpasswd in favour of a full tdb-style SAM database." Elrond was a bit upset at this: "You remember the BROKEN KCREF Currently one can't even transfer a tdb from a big-endian to a little-endian machine (unless I've misread the code). And one reason, we're all using Unix/samba is, because we don't like 20MB binary databases, noone can handle..."

Luke and Jean-François both pointed out that one could still translate a tdb database into a text file and back. Jean-François said, "you would have to run: tdbexport smbpasswd|vi|tdbimport smbpasswd. tdbexport and tdbimport are not available but we haven't switch to a tdb for password yet."

On cue, I produced a rough but working tdbexport to produce binary-portable formats such as text and RFC-1341 BASE64. Tim Potter promptly noted that a portable format wasn't everything: "I've been thinking about this - currently there's no way to determine the type of some data stored in a tdb. So I think it is therefore impossible to write a tdb exporter that can handle byte-ordering dependencies as this information is not stored in the tdb!" I admitted,

True! I was thinking only of the byte order of the file format itself -- content is completely untouched. This is still useful for textual tdb data like smbpasswd and wins.dat, and that was the real intent.

If you're going to start worrying about storing byte order for arbitrary binary data, don't forget that people are dumping arbitrary structs in these things. So now you have to talk all about word sizes, structure packing, floating point format, 1's/2's-complement (:, etc. In the end, I doubt it's worth it.

Hiroshi MIURA posted the announcement for an internationalized version of Samba 2.0.7, featuring in particular much-improved Japanese support. From the announcement:

We proudly announce the Samba 2.0.7 Japanese Beta edition, which supports the internationalization(I18N) of SWAT: Samba Web Administration Tool.

We strongly propose the new SWAT I18N implementation. Please check and include it in Samba 2.0.8.

This version is shipped as the Japanese edition. But precisely, it should be called a MUCH MORE ADVANCED I18N and L10N implementation edition.

This version is still beta because it is tested by few developers and users in Japan.

It is completely upper compatible to Samba 2.0.7. However, please pay attention when you have used particular Japanese characters, not supported in the prior versions.

This compatibility issue occurs in the machine dependent characters and user defined characters because of the incompleteness of the localization in the prior versions.

In the prior versions these characters may be stored in the code different between versions. And in most of prior versions some of them were treated as control characters.

Now we've just supported them.

But you have to take care of using this version if you have used these characters in the prior versions. About such characters, it is basically impossible to take matching between versions.

We report this problem to SAMBA Team and hope to fix it.

In addition, if you have used old Japanese edition, Samba 2.0.5a-JP1 and Samba 2.0.5a-JP2, you should carefully operate to migrate them to Samba 2.0.7-ja. The documents about migration are now written in only Japanese, anyone wants them in English version? :-)

OK, so maybe "2.0.8 Release Plans Cancelled" is a bit misleading. Jeremy Allison posted the following request for discussion on samba and samba-ntdom:

I'd like to ask to make a version number change for the next stable release. Currently we're planning to release something we're planning to call 2.0.8.

However, what I'm actually busyly creating in the CVS tree is HEAD minus vfs and dfs and some of the TNG mods.

This is a very big change to call 2.0.8, which implies a minor rev. on 2.0.7.

Now I still want to ship this code as the next release, as it is significantly better than what otherwise would be in 2.0.8. I will go into more details on the changes in a later email, but this code is definately more robust and correct from an SMB standpoint than the 2.0.x code.

But I'd like to call it 2.2.0 instead. That way people know this is a more significant change, and will hopefully do more testing before slotting this into a production system.

Predictably, for such a minor issue, there was Much Ado. Mike Warfield asked if the idea was to use the Linux kernel versioning scheme, and Jeremy confirmed this. In that case, I wondered, would there actually be odd-numbered minor versions, as opposed to just CVS access as is current practice?

But the biggest non-issue turned out to be pre-existing documentation, much of which refers to "version 2.1" as the Samba release with full NT domain controller functionality. Steve Williams noted: "I have the O'Reilly "Using Samba" book, and in it there is a paragraph that states (page 186): "You will need to use at least Samba 2.1 to ensure that PDC functionality for Windows NT clients is present..." If the new version makes that an invalid statement, then I'd be concerned about "newbies" out there having problems..even after they have RTFM'd!!"

Tim Cole wasn't worried. "I think in effect what's happened is that the development roadmap has changed. The general expectation a while back (when that text was probably written) would be that the next non-2.0 version would have all of the PDC goodies and whatnot. But, that's not really feasible at the moment, and there are enough new changes to warrant a 2.2 release, I think. So, the book made predictions about Samba development based on the roadmap at the time, only the roadmap's changed now. It happens. *shrug*"

Not everyone was satisfied with this, and the argument waged on for a dozen or so messages. Meanwhile, I asked Jeremy if he might consider releasing a "2.0.7a" to fix a few of the obvious 2.0.7 errata. No reply.

Jerry Carter, in preparation for upcoming Samba support for Windows NT-style print spooling, announced on samba-ntdom the formation of a new SIG, the Imprints Project. "Imprints" was said to stand for "Installation Manager of Printer driver Retrieval for [I.N.T.] Samba." Jerry continued,

The following goals have initially been laid out:

develop a tool set which can be used to create, distribute, and install the printer drivers files needed by Samba to support automatic driver downloads for Windows 9x and Windows NT clients
design and implement a central database/directory which can be queried to locate the most current set of Windows 95/98/NT printer drivers needed by clients. (note that the population of this database is another matter entirely).
document the entire process in order to provide Samba administrators with the resources necessary to take advantage of this system.

Currently these three goals are in the planning stages.

I would like to invite all who would like to participate in the newly planned Imprints Project to subscribe to the development mailing list at

http://lists.sourceforge.net/mailman/listinfo/imprints-devel

The list archives can be found at

http://www.geocrawler.com/lists/3/SourceForge/3860/0/

If you have questions, feel free to email me directly.

Ron Alexander asked samba-technical for help with some strange behavior he noticed when running Samba from inetd on VOS. I opined that nmbd in particular should probably not be run from inetd, although I was unclear on the details of the problems to be expected. This really confused Ron: "Can someone PLEASE tell me if using inetd is the recommended way or not? According to all the books I have, it is recommended."

Several people seemed surprised at this, asked where Ron had read this, and generally agreed that it was wrong. John Malmberg, as usual, brought up a less Unix-centric perspective: "On OpenVMS, nmbd is run as a daemon, but smbd is run from the inetd equivalent. This is a result of not having an efficient fork() capability."

As it turned out, Ron's books hadn't precisely recommended using inetd, but they hadn't discouraged it either. He also eventually learned that the strange behavior that started the thread was a local operating system bug. The thread veered into trying to troubleshoot Ron's connections which weren't getting through his firewall, and finished inconclusively.

Having painted myself into a bit of a corner, I asked for help on samba-ntdom:

But I have discovered something this morning, or rather I have failed to discover something.

How to create the default value for a registry key. Remotely.

NT REGEDT32.EXE won't go near a remote hkey_classes_root.
NT REGEDIT.EXE pleads lack of permission to add values.
TNG rpcclient ... well, it can add keys and values just fine, but I can't get it to add the default value for a key.

The issue is that I went through and deleted everyone's reg key:

    hkey_classes_root\.VBS

which I now can't recreate for the machines I want to, because it's supposed to have a default value of "VBScript".

In REGEDIT.EXE this shows up as the value named "(default)". If you export to a .REG file it is represented by "@".

Luke? Anyone? Is there a way to do this in rpcclient?

Luke promised to look into it. A few days later, Todd Sabin had the right answer: "Well, these values which show as "(Default)" in regedit (and "<No Name>" in regedt32) actually have "" as their value-name. Yes, that's the Null string. Why MS lets you create values with no name is beyond me. Anyway, samba-tng's rpcclient (at least) can create these with a small patch." He posted the patch, which turned out to be trivial, and concluded, "With this patch you can do, e.g.,

So now rpcclient from Samba-TNG can access remote registries just as well as REGEDIT from Windows NT can. [Oh, it still can't manipulate ACLs on keys & values. Even so, this is very good news for any Unix administrator in an NT environment. Updating everyone's registries from a shell script is very handy indeed.]

Aleksandar Samardzic posted to samba-ntdom, asking (among other questions): "How to achieve synchronization between regular Unix and Samba password later (I know for Samba->Unix password synchronization, but what about reverse side)?"

Meanwhile, Doug Irvine posted a similar question, also to samba-ntdom: "If anyone knows where I can get a source of samba that the "pam_smbpass" module from ftp.netexpress.net will compile against, or if there is another solution using PAM or somehow else automatically updating smbpasswd when "passwd" is used on the unix side--I would greatly appreciate some direction ;)"

This is a semi-frequently-asked question, so I wrote a small PAM module by way of an answer. I explained,

It sits and snoops whenever a user enters or changes a password through PAM, and sends the passwords off to be processed by an arbitrary PAM-unaware executable. That means:

For all logins (ftp, ssh, telnet, pop3, etc) you can grab the password and use it to populate your local smbpasswd file. This is akin to the smb.conf `update encrypted' option, useful for migration from a Unix environment to a mixed Unix/NT environment.

For Unix password changes, you get both the old and new password, so you can either do the above, or update an NT domain controller (or remote Samba domain controller). Assuming your NIS domain controller is PAM-aware, this should work for `yppasswd' as well. (Untested.)

Steve Langasek pointed out that mine wasn't the only method for achieving this: "pam_smbpass has allowed people to do this for a while using PAM. But pam_smbpass is in a state of flux right now, and more PAM modules are always welcome. :) As you say, pam_pwexport isn't specific to Samba, either."

Nick Brealey figured out how to get the module to compile on Solaris, Steve fixed a memory leak, Doug helped track down a few odd bugs in an example script, and Elrond had an idea for a completely different approach to updating a remote PDC using the same module. A good time was had by all.

The SecureXpert Team reported, on samba-technical, a trivial denial-of-service bug in all versions of Samba: "By connecting to port 139 on the machine and sending it binary zeros (i.e. netcat target.machine 25 < /dev/zero), the machine will remain in a resource consuming loop, and drive the CPU load to somewhere between 90-100% (while keeping the load on the target machine relatively low). This was performed on a LAN, in our tests. Over a port-forwarded SSH loop between DSL machines (getting a maximum performance of about 100 kbps), the machine was driven to a utilisation of 49% consistently, with negligible load on the attacking machine. This suggests that a distributed attack quite possible with a relatively small number of connections; a large number of connections could allow one to keep the remote machine's load extremely high for arbitrarily long periods of time."

Michael Allen reported that he couldn't reproduce the bug. Chris Hertel responded, "Perhaps we need further info on the configuration of the original test systems." J. Robert von Behren managed to reproduce it, though, and had an idea for a fix: "After watching smbd with gdb and strace, I found that the child smbd that was spawned in response to the nc connection just keeps reading zeros from the socket, and writing out error responses, ad infinitum. A simple fix would be to abort the connection after a certain number of successive bad requests, or after a certain number of bad requests within a given time period."

Jerry Carter said, "But let's put this into perspective. Everyone should know that if they allow the standard NetBIOS ports through their firewall, the are asking for it. If someone on your internal network does this, you yank their network cable for a week minimum and bang on their head with a rubber bat. :-) Let's address the risk. I know the DoS is real, but is it realistic. Just asking. No flames please."

Chris: "It's not just TCP. nmbd displays the same behavior when I fling large numbers of zero'd packets at it. Under UDP, the goal is to fling the packet to the floor with as little effort as possible. You can send back the appropriate ICMP to signal that the connection is closed or the port is unreachable or some such. I'm not sure which is correct. You might also silently drop the packet on the floor and not waste effort."

I think there is a bit of confusion on this point. nc/netcat will create exactly one tcp connection to the specified port, and then dump stuff at it. Hence, in the ps output you showed below, there were only two smbd processes - the listener, and the one processing the bogus commands. Recognizing and handling bogus commands requires user-level parsing of incoming data, and hence should be handled by the child smbd process. Doing early drop of spurious connections is an entirely different issue, and should be handled differently.

IMO, all of the solutions that have been posed for handling single connections with a sequence of bad commands are reasonable. Unfortunately, dealing with DOS attacks that create many connections are much more difficult to thwart. The only true way to thwart these is to have the kernel do IP-address filtering (similar to tcpd), and drop any connections from hosts that are determined to be bad citizens. If we have to fork another smbd process before this drop can occur, then we will have already lost this battle, as an attacker could easily cause us to spawn an ulimited number of smbd processes (or simply use all available smbd processes up with bogus connections). This is a well known and well studied problem with web servers. The resource containers paper from Peter Druschel's research group at Rice gives a good description of this, and how you can solve it with an appropriately designed network stack: http://www.cs.rice.edu/~gaurav/papers/osdi99.ps.

For our purposes, I think the best we can hope for is to keep track of IP addresses that are causing problems, and blacklist them for a time. A policy like "after N bogus connections from a host, drop new connections from that host for M minutes" would do the trick. "bogus connections" would be defined as connections that had to be killed b/c of too many bad SMB commands.

Luke Leighton had been fairly quiet (for him) on the mailing lists for a few weeks, and he finally dropped a hint to samba-technical as to why: "anyone interested in writing an auto-generated SMB client and server?"

It was a tantalizing post, and Tim Cole took the bait. "Seriously, what brings this up? Did you get the entire SMB ball of wax laid out in UML or something from somewhere?" Luke explained, "no, i took draft-leach-cifs-v1-spec-01.txt, cut/paste bits of it into idl/smbfn.struct, compiled it with an awk idl compiler andrew started a couple of weeks ago, and auto-generated some code. cvs co cliffs."

Translation: he took an SMB spec written by Paul Leach of Microsoft, extracted portions written in the Microsoft Interface Definition Language, and ran it through Tridge's set of awk scripts for compiling MIDL files. He published this work through the Samba CVS archive, as the `cliffs' module.

This thread portends some changes in the bleeding-edge Samba development. Expect to hear more about auto-generated interfaces and less about Samba-TNG alpha releases. So far, Luke reports having come a long way in a short time, and he seems to be enjoying it. "despite the obvious complexity and mess of dealing with the SMB protocol, this stuff is actually quite a pleasure to work with."

In closing, we look back with some amusement to Tridge's prognostication concerning Luke last December (see BROKEN KCREF): "I am also pretty convinced that no matter when we decide to try to merge your development code in, by the time we are done you will once again be complaining that we shouldn't be using that old crud and should instead be using your all-new way of doing things whatever that might be."


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	10 May 2000 - 14 May 2000	(12 posts)	One Client in Multiple Domains?
2.	12 May 2000 - 18 May 2000	(32 posts)	RID Generation and TDB Password Files
3.	15 May 2000	(1 post)	Japanese Edition of Samba
4.	18 May 2000 - 20 May 2000	(46 posts)	2.0.8 Release Plans Cancelled
5.	19 May 2000	(4 posts)	The New Printing Committee
6.	19 May 2000 - 21 May 2000	(24 posts)	Inetd+Samba Considered Harmful
7.	20 May 2000 - 25 May 2000	(11 posts)	Basic REGEDIT Functionality Now Complete
8.	10 Jun 2000 - 17 Jun 2000	(17 posts)	Passwd -> SMBpasswd Synchronization
9.	14 Jun 2000 - 15 Jun 2000	(26 posts)	Simple Denial-of-Service Attack
10.	17 Jun 2000	(4 posts)	Samba in AWK?!?

Samba Traffic #24 For 30 Jun 2000

By Peter Samuelson