Samba Traffic #23 For 18 May 2000

Glen Eustace reported another Samba 2.0.7 bug, this one with printing in Digital Unix, but since he upgraded from Samba 1.9, it's unknown if this is 2.0.7-specific. Other than that, we haven't heard of any new problems with 2.0.7, so Jeremy Allison is now merging large parts of the HEAD branch into what will be the next stable release.

In fact, the three major branches of Samba development are starting to look more and more alike -- much of HEAD has now been merged into SAMBA_TNG, and CVS logs show that most developers that apply bug-fixes to one branch are applying the same fixes to other branches. There seems to be some effort expended these days to keep the branches as much in synch as possible. This is most definitely a Good Thing, and quite a departure from a few weeks back, where nobody but Luke ever touched SAMBA_TNG and he almost never touched the other branches.

There were 174 different contributors. 66 posted more than once. 46 posted last week too.

Martin Helas posted to samba-technical with an offer: "i'm watching the samba mailing-list for half a year now and sometimes it seems to me that the questions asked in the list are more or less the same. Now TNG get in a good state, where documentations should be written as well as FAQs and HowTos. I would like to help writing documentations, especially in german. But english would no problem for me, only someone should read over it, to check 1. my english as well as the technical point of view. I could also imagine joining a group, who is already doing this." Jerry Carter forwarded this note to samba-docs, saying, "Anyone want to give Martin a push in the right direction?"

Martin reaffirmed that he would be interested in perhaps writing a HOWTO on Samba-TNG, and Jerry suggested he work with Lars Kneschke, whose web site is currently the best known resource for Samba-TNG documentation. Lars put in a summary of what features in TNG seemed to be working, but cautioned that the everything was still somewhat volatile. "But i think that good documentation takes time too, so it's better to start now than to late. I would like work with Martin together, to create some documentation. I'll contact him in private mail(in german :-))."

Martin then put up a draft of some documents. Others put in various suggestions about them, and Mark Komarinski said, "You may want to drop the LinuxDoc and sgmltools 1.0.9 in favor of DocBook, which the LDP is moving to. I've written the HOWTO-HOWTO (on http://www.linuxdoc.org) to help authors get using DocBook, and would be happy to help you out."

Back in early April, Chris Young expressed some curiosity about the Kerberos authentication support claimed by Samba. He posted to samba-technical:

Ok, I've been reading through several of the Samba lists and have found enough information on this to just confuse me furthur. I'm attempting to get a strong understanding of the status of Kerberos 5 support in the current development versions of Samba.

Basically, I would like to standardize our network's authentication structure and right now, Kerberos seems to serve this purpose best. I understand that Samba has compilation option to enable Kerberos support, however I don't quite understand how this comes into play. I've been looking through the code (althought my programming skills leave alot to be desired) and everything is still not clean.

I would appreciate a good summary of where Kerberos support is currently and where it might be heading so that I can plan everything accordingly.

The basic questions that I have regarding Samba and Kerberos are:

If Samba support Kerberos, does this mean that it actually support Kerberos TICKETS or does it just merely take the encrypted (or, most likely plain text) password and pass it on the the KDC for a yes or no?

If this IS the case, then what is the difference in this approach vs. using Kerberos PAM modules and configuring Samba to use PAM for authentication?

Jeremy Allison answered, "Currently smbd takes the plaintext and passes it onto the KDC for a yes/no." He elaborated: "The real kerberos ticket support (ie. using the tickets granted from a Win2k KDC) is targeted for 3.0. We need to do more work on analysing the packet format (Luke knows more about this) before implementing this."

Funny he should say that! The thread probably would have died, but three weeks later, Microsoft rescued it by pulling their now-famous Kerberos Stunt, perhaps the most bizarre interpretation of US intellectual property law in recent memory. [For those who missed the hoopla, Microsoft published the specs to their Kerberos extensions in Windows 2000 Advanced Server, making a PDF file freely available for download (embedded in a self-extracting Windows .CAB file) while simultaneously claiming that it was somehow still a trade secret and protected as such under law. The real twist was that if you opened the .CAB file using its own self-extracting mechanism, as opposed to via a third-party utility such as Winzip®, you had to click an "OK" button agreeing to an embedded NDA. The NDA forbids you to share the "secret" and also forbids actually implementing the protocol described. Apparently all you are allowed to do with it is review it for security purposes. At the time of this writing, nobody seems to be quite sure yet which, if any, of Microsoft's claims are legally valid.]

Chris Hertel, referring to Microsoft's Kerberos extensions NDA, opined; "The "license" appears to be designed to prevent an Open Source implementation. I really have no idea what they are thinking. Perhaps, should an Open Source implementation appear, they are hoping that they could tie people up in a legal mess. The real question, however, is this: What do we gain from knowing how these fields are layed out? They likely contain information specific to W2K. Samba jumps backwards through flaming hoops as it is trying to generate valid-looking W/NT IDs." The discussion turned to whether and how to implement the MS extensions in Samba without getting into legal trouble. Nico Williams summed up one point of view:

Luke posted the IDL description of the user profile structure to the XAD list not too long ago. So that much is known publically through means other than reading the MS spec.

Also, several public MS docs describe enough of the mechanism that it can be reverse engineered.

Samba will have to play a role in any KDC/ActiveDirectory open-source replacement project as MS added a call to the NetLogon protocol to validate the KDC PAC signature. (All of this is public knowledge). Samba has the only open-source implementation of various MSRPC protocols, including NetLogon.

Moreover, if you go read the Kerberos mailing list archives you'll see that one of the MIT team members says that parts of the MS PAC were discussed a long time ago on those same lists in detail.

If you put it all together it may be possible to obtain 90% of the details of the spec without reading the MS secret spec.

If anyone is serious about starting such a project then they'll have to document all their sources for any information about the MS PAC and any reverse engineering efforts.

There was also no little discussion the technical points, particularly the question of what the "secret" extensions were actually useful for and whether Samba could do without them. Dave Lindner said, "If a unix user does a kinit type operation (whether this is done automatically when the user logged in, or whatever), that tgt obtained from the w2k kdc contains all the lovely secret pak data, and its on the unix box. Whoopy do. For unix auth, and for Samba auth that unix identity is the important part, because who I am on unix determines what I have access to. I can still hand that off to other windows services that might care about that pac data, but on Unix that pac data is opaque data that I don't care about." Jeremy Allison agreed: "Samba can survive without the PAC, but can MIT kerberos or Heimdal ? That's why it's essential to get the status of this widely distributed "trade secret" clarified legally." But Phil Mayers had a somewhat different point of view:

Getting the right data to put into the PAC isn't hard, Samba can pretty much do that already, it's knowing what format to put it in. The clients will automatically use the PAC data once it's there (calling the NT equivalent of setgroups() with the given group data, before setuid() down to the user).

Similarly, NT server which are passed a K ticket from the client will "automatically" make use of the data, applying access permissions based on the group SIDs in the ticket.

Non-NT server can either

Ignore the PAC, and look the groups up from some database
Decode it, which requires the format.

I'm proposing SMBD do the latter, which passes almost all responsibility for Win2K Kerb tickets onto the KDC (it's called buck passing...)

NOTE - almost all - as Nicolas Williams points out, NETLOGON has to be able to validate a supplied K tickets' PAC signature, but I suspect some kind of "cache" of issued PACs could be used to do that without too much trouble. I hope, otherwise the problem could be harder than we think.

The conclusion seemed to be that in order to make much use of the ticket data, Samba would have to do something meaningful with the arbitrary SIDs involved, so that started another mini-discussion, this time about using the NT SID/RID authentication model in Unix. Nico Williams wrote: "Remember, most modern Unix kernels (*BSD, Solaris) (Linux?) already store POSIX creds in a fairly opaque cred_t struct type and provide utility functions for comparing uid_t and gid_t values to a given cred_t value. So it should be possible to re-shape the cred kernel struct to be extensible, e.g., to support multipe credential types, without having to re-write any or much existing FS driver code." He added, "You'll also need to deal with the Unix real vs. effective credential model. That is, it would be nice to have a real vs. effective SID/RID :) and it would be nice to have setsidrid bits in permissions masks on files." Steve Langasek said that the Linux kernel, at least, does not have any "opaque cred_t type" yet.

[If any of you are like us and a lot of that was a bit over your heads, just nod quietly and agree with Chris Hertel:

What pleases me most about this conversation is that we seem to have some very knowledgable folks on the list and that there is progress being made. Time for me to go into learn mode. Thanks everyone!

Jens Skripczynski offered, on samba-ntdom, to write a PHP Samba-bug-web-form. The idea was for consistency of bug reports as well as encouraging people to give complete information. At one point Seth Vidal proposed: "I know this a radical concept but maybe its worth considering a BTS like bugzilla or debbugs. It would seem reasonable. does samba already have a BTS? if so can they provide a branch for TNG?"

As it happens, Tridge's own jitterbug was written expressly for his open-source projects, including Samba. Luke Leighton pointed out: "yes, we have jitterbug. we switched it off after the messages remained at 15,000 or so after a couple of years." Sam Couter wryly replied, "No bug tracking system is ever going to work if the developers don't use it." (It might also be noted that the jitterbug installation on samba.anu.edu.au was the same system Linus briefly tried to use as a patch queue for the Linux kernel some years back. That lasted two or three months -- then Linus decided it was unnecessary, and went back to just taking patches via e-mail, as before.)

Keith Davey, meanwhile, offered the use of a spare machine to run bugzilla. There was no resolution, but it does seem that if Tridge's own bug-tracking system fell into disuse, a competing one might not fare any better.

Ron Alexander, neck-deep in his work to get Samba to run on VOS, asked samba-technical: "Is there any way to 'turn off' the code page logic. The platform I am porting to does not have codepages." Neither does anyone else, replied John Malmberg: "The codepage routines are for platforms that do not have codepages. They are pretty straight forward routines and do not seem have any platform dependant stuff. If you do not build the separate codepage compiler, and then compile the supplied codepages, SAMBA will still work, it may log a diagnostic about using a default codepage."

Ron was still confused -- what did codepages do, then? Could he configure them out? The real trouble seemed to be that he was getting warnings -- which he admitted were probably harmless -- in the log files about missing code pages. "It might seem like a nit, but I know somebody in the user community will call me at 4:00 in the afternoon. The problem is, they will be in Singapore." So Steve Langasek explained the whole codepage issue from the top:

All of the codepage support is internal to Samba: there is no codepage support in the underlying OS. All of the codepage files that you see Samba complaining about are supposed to be generated by a utility that's included with Samba.

The problem is that even though Unices don't support codepages, Microsoft clients do, and in fact depend on them for proper display of filenames. The codepage support is used in order to convert from the OS's native character set (usually something like ISO-8859-* or a Unicode variant) to a codepage that can be understood by Windows.

So the answer to the question "what do they do to get rid of the diagnostic messages?" is that they build the make_smbcodepage utility from the Samba distro and use it to populate the codepage directory.

I have updated my version of how to get "nls" working in smbfs for the changes made in the 2.2.16pre2 Linux kernel (both nls and smbfs). It is now a bit smaller and perhaps cleaner (except for the CONFIG_SMB_NLS, that could be removed, and the nls_utf8 abuse :)

Also, it now uses an ioctl to set the codepages to use (borrowed from the work by Artem V. Ryabov). This allows you to mount a modified smbfs with an unmodified smbmount or vice versa and that should give less "version support" than my old modified mount_data variant.

One thing that has been removed is the support for a "default mapping", this means that the patched version should behave like an unpatched version until you ioctl it.

He posted URLs for the kernel patch and the smbmount patch. He noted that an patched smbmount will not compile with an unpatched kernel, though it would work with one, and concluded: "More testing, comments, bugfixes, modifications to appease maintainers :) and eventually being applied to official trees are needed."

Also on the subject of smbfs, Heribert Schütz had a question, also on the samba list, about permissions for deleting files. He had noticed that Microsoft operating systems would not let you delete a file you did not have write access to, whereas in Unix the convention is to allow it if you have write access to the directory the file is in. (This goes for renaming as well.) He was using smbfs and the semantic difference was causing problems. In a separate thread, Craig Pratt had exactly the same complaint.

Urban responded: "You may want to try Linux 2.2.16-pre2. It has included a patch to try to chmod and then unlink again, if the first unlink fails. It should also work to copy the unlink change from 2.2.16-pre2 to whatever version you need/want to run."

Gene Yee had consulted books, newsgroups and even people at Microsoft, but nobody could give him a good answer so he tried the samba-ntdom list: "When a workstation logs onto a domain it can locate a DC via broadcasts or WINS. If it is located via broadcast it is obviously going to be the nearest server. If it is located via WINS, how does the workstation know not to go across a slow WAN for authentication? How does a workstation decide which DC to use for authentication?"

Paul Collins answered: "I seem to recall hearing that the client gets a list of all the DCs in the WINS and sends a request to each of them and then picks the one that responds first; a focused broadcast, if you will. NetBIOS names with type 0x1c are domain controllers, I believe." Anders Thorsen guessed that it might go by IP subnet, and Gene put in, "The ip/subnet wouldn't tell the workstation which is the closest/fastest DC. I'm wondering if the workstation what keeps the workstation from trying to authenticate with a DC over in Asia if I am in California."

multi-stage, and yes, it's chatty, and insecure [all based on UDP].

nbt 137 lookup domain<1c> bcast & wins. fail?

nbt 137 lookup domain<1b> wins & bcast. fail?

nbt 137 lookup domain<00> bcast. fail? failed?

any success: from nbt 137 contains ip of pdc or bdc.

nbt 138 GETDC to ip-of-domain<xx> from above. fail? failed.

success: response contains name-of-server.

nbt 137 lookup server<00> wins & bcast. fail? failed.

success: now you can do an SMB session request.

this is not all, there are bits left out.

now, is anyone curious as to why it sometimes takes 30 seconds to time-out if your DC can't be found?

Seiichi Tatsukawa added, "And don't forget that the Service Pack changes the selection behavior, e.g., SP4 prefers DCs responding to the broadcast, which kinda makes sense because they are likely near you... Then, there is "setprfdc" command (Q167029, Q181171)."

Ron Alexander reported that nmblookup was hanging. He posted the output of the program to samba-technical. Dave Collier-Brown replied, "Off the top of my pointy head, sounds like a problem in the select/socket code... Do you have a call-tracer like truss or strace?" Ron didn't, but he had a debugger: "Here is what I see in my debugger.

Ron said, "Sorry for disturbing everyone, when I ran the test in the debugger, I finally recognized that select was misbehaving!" But then, not long after, Richard Stevens' standard work Advanced Programming in the Unix Environment changed his mind: "On page 399 of Stevens the last para. deals with the select situation. As usual, there are 2 behaviors for timeout. 4.3+BSD does NOT change the desc. set while SVR4 clears the set. The VOS implementation is the BSD version. Samba assumes SVR4 behavior. The patch that David supplied is ok, but only deals with one caller of sys_select. The real fix must be made in system.c. The question then is if the Samba sys_select should be BSD or SVR4 style. The simple fix is to adopt SVR4 since clearing the fd's is less overhead than restoring them. See client.c wait_keyboard for another example of code that will fail."

Dave objected, regarding the select file descriptor set, "Neither change the set on error." He continued,

There are three possible errors from select, and two possible successes (the second is a timeout). the code handles one error and both successes, but thinks the other two errors are successes.

That is, regrettably, A Very Bad Thing

I therefor turned this into a three-possibility check: success, failure (any of the three) or timeout. It is the least code to cover the cases, and I strongly recommend the team apply the fix or an equivalent one.

Jeremy reported already having applied Dave's patch, whereupon Dave promptly produced another patch fixing to a bug in the first.


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

1.	27 Apr 2000 - 10 May 2000	(24 posts)	New Documentation Volunteer
2.	11 Apr 2000 - 9 May 2000	(21 posts)	The Microsoft Kerberos Issue
3.	5 May 2000 - 9 May 2000	(11 posts)	Bug-Tracking Systems?
4.	8 May 2000 - 9 May 2000	(5 posts)	What Do Samba Codepages Really Do?
5.	9 May 2000	(1 post)	Character Sets in SMBFS
6.	10 May 2000 - 11 May 2000	(9 posts)	How NT Finds a Domain Controller
7.	11 May 2000	(10 posts)	`select' Semantics

Samba Traffic #23 For 18 May 2000

By Peter Samuelson