Samba Traffic #9 For 26 Jan 2000

By Peter Samuelson

Table Of Contents

Introduction

Last week I had to confess that I had "no idea what changed in NT4 SP4." Ben Tilly was kind enough to clue me in. "Basically Microsoft failed to get a FIPS 140 security certification, it was a scandal (reported several places and since pulled from most of them, I don't know why) and so SP 4.0 did a lot to lock down NT machines. That also broke a lot of stuff..." Thanks, Ben! (And here I thought SP4 was just Microsoft's excuse to make us all cope with Active Desktop.)

List traffic has strange patterns. This week well over 50% of it has been on the samba-ntdom list. Come to think of it, this may not be so strange. NT Domain support is, after all, Luke Leighton's specialty, and he singlehandedly accounts for 20% of the total volume. (And yes, that volume includes all the bug reports where people list their entire smb.conf files.) To quote Andrew Tridgell, "Does he ever sleep?"

Perhaps the biggest generator of list traffic was shared libraries; specifically, Luke's adventure with moving some of his code into shared libraries, and the mayhem of bug reports this spawned. It seems to be settling down quickly enough, thanks to a lot of hard work hacking the GNU libtool infrastructure into place.

Mailing List Stats For This Week

We looked at 612 posts in 1252K.

There were 194 different contributors. 77 posted more than once. 63 posted last week too.

The top posters of the week were:

1. Win95 Profiles/Home Directories Madness

14 Jan 2000 - 16 Jan 2000 (11 posts) Archive Link: "net use/home versus profiles"

People: Richard SharpeGiulio OrseroGuilio OrseroLuke Leighton

We briefly discussed, in Issue #8, Section #2 (sm_20000120_8.html#2) , the problems people are having with Samba 2.0.6 and Windows95 profiles. The situation is somewhat complicated, but the crux is that Samba behavior changed between 2.0.5 and 2.0.6, surprising a lot of people who thought 2.0.6 had a bug.

Well, it turns out not to be a bug -- or, at least, not a Samba bug. Richard Sharpe posted to samba-technical: "I have logon path = \\$L\profiles and I have directories already created for each user in the profiles directory on the server ... with the correct permissions ... However, profiles are not going in the directory above. I have a trace of a log on and log off, and lots of stuff is getting written to USER.DAT on the home share, but nothing to the profiles share ..." Giulio Orsero posted a quick analysis of the situation. Richard then did a little homework with his network tracer, and reported back:

When you do a net use /home, Win9x sends a NetUserGetInfo with a detail of 11.

Samba 2.0.6 fills in the usri11_homedir with lp_logon_home, not lp_logon_path.

However, when Win9x is logging off or on, it also does a NetUserGetInfo request with a detail of 11. Samba also returns lp_logon_home in the usri11_homedir field.

Now, Samba cannot distinguish between the user doing a logon and the user doing a net use /home. Unless Win9x does something different if it detects a real NT server, then we may be hosed.

The point of confusion, then, is that Samba has two config options, "logon path" and "logon home", which mean different things for NT clients, but the protocol used by Windows95 does not distinguish between the two, so Samba has to choose one or the other. 2.0.5 used logon path and 2.0.6 uses logon home.

Two other interesting facts came out. First, it seems that a Windows95 client does exactly the same thing with an NT server, so it's not just a Samba problem after all. Second, this Win95 bug can be worked around by taking advantage of another Win95 bug! Giulio describes this horrible but clever hack: "Using logon home = \\%L\%U\profile" [editor's note: %L and %U are expanded into the Samba server name and the username, respectively] "put the profile in the profile dir and at the same time let net use /home work because the win9x clients truncate the \\%L\%U\profile to \\%L\%U (valid share)" In other words, by exploiting this second bug you can store a Win95 roaming profile in a subdirectory of the user's home directory, though you can't put it outside the user's home directory.

Luke Leighton wrapped up the discussion: "oh well. at least we can be bug-for-bug compatible with NT on this one." One gets the feeling that this is something he has had occasion to say before....

2. The Truth Table Contest, or Fixing What Ain't Broke

16 Jan 2000 - 18 Jan 2000 (29 posts) Archive Link: "access_table() challenge - win a Samba t-shirt!"

People: Andrew TridgellOsama Abu-AishMatt ChapmanLuke LeightonJeremy AllisonJohn Malmberg

This one was interesting. Andrew Tridgell had a perfectly working mapping function, but he didn't understand how it worked, so he wondered if anyone could come up with an identical function with simpler logic. He posted to samba-technical:

I've just spent quite some time re-doing our deny mode code in Samba. We now pass (ie. match NT4) on all possible deny mode combinations.

The core of this code is a function called access_table(). It works out what access is allowed by a second open when there is an existing open on the file. It looks like this:

  static int access_table(int new_deny,int old_deny,int old_mode,
                          BOOL same_pid, BOOL isexe)
  {
  ...
  }

the first two parameters can take on 6 different values, the next parameter can take 3 parameters, the last two are boolean. The result is one of 4 possible values.

The challenge now is to recode access_table() so that it is as small as possible. Right now it is horrendous, but I suspect there is an underlying pattern that I have missed.

So, if you want to win a Samba tshirt from nerdgear then grab ftp://samba.org/pub/tridge/misc/atable.c and modify access_table2() so that it is small, neat and generally appealing. Then make sure that it still works. Send me the resulting function. The function I like the best gets the tshirt.

Those of you good with digital logic problems should find this easy :)

A lot of people seemed to want to win the T-shirt. Osama Abu-Aish posted some header file fragments to try and clarify what certain constants might represent. He also agreed with Tridge that this was really a digital logic problem: "Any VHDL-Programmers here? It should be easy to convert the code to VHDL and let a VHDL-Compiler do the optimizing / decoding :-)" Luke Leighton and John Malmberg had similar thoughts.

Matt Chapman posted a partial solution, choosing to opt out of the hard part: "DENY_FCB is not a real deny mode, and should be handled further up the call chain." Tridge reported: "Paul Mackerras tried his logic simplification program but it produced someting even less readable than the current code."

Another of Luke's ideas: "ok, so we translate the whole lot into SEC_ACCESS bitmask permissions, create an ACE-checker (which does SEC_ACCESS_FULL_CONTROL asa special case), and see what happens." No good, said Jeremy Allison: "the deny modes are nothing to do with the SEC_ACCESS stuff. They are not ACE's." He later clarified: "They're just not the same things. DENY_MODES are, well, DENY_MODES - they relate to multiple simultaneous opens. The SEC_ACCESS stuff is to do with the underlying security on the file. Different kettle of fish."

The contest was over two days later. Tridge announced: "I've now had submissions that produce what must be close to the minimal logic. The joint winners are Matt Chapman and Paul Mackerras." He awarded two T-shirts, explaining the reason for the tie: "Matty gets one as Paul used Mattys analysis to produce his code."

3. Samba-TNG: Beware of Core

16 Jan 2000 (1 post) Archive Link: "[SAMBA-TNG] possible memory corruption"

People: Luke Leighton

A single post, by way of announcement. "there may be some memory corruption occurring that andrew noticed evidence of, in TNG. at his suggestion, i put in a mini realloc in parse_prs.c that always moves memory about. the idea is to catch memory corruption ASAP. so, if you get any coredumps (grep INTERNAL log.*) please send in the usual full report [recompile with ./configure.developer; gdb bt full on the core file etc etc]."

[For all your neophyte programmers out there: what Luke is doing is a variation on those "malloc debugging" libraries such as dlmalloc and electric-fence. One is also reminded of Alan Cox's use of "slab poisoning" in his Linux kernel 2.2.13 pre-patches, when everyone was trying to find an elusive allocation bug in 2.2.12. The slab poisoning really worked, too: it helped nail about half a dozen unrelated allocation bugs before it caught the one they were looking for.]

4. Printing to an HP JetDirect Adapter

16 Jan 2000 - 18 Jan 2000 (8 posts) Archive Link: "Different ports"

People: Keith LynnPhil Burch

This one was a bit off-topic. Keith Lynn wondered (on samba-ntdom, of all places): "I have an HP JetDirect print server which has an IP address and three ports that I can plug printers into. How do I get Samba to recognize the printers?" This is really a Unix question, more than a Samba question.

Quite a few people knew that HP's JetDirect line of network print servers has builtin Berkeley LPD support, so you should be able to treat it as just another remote print queue. Phil Burch had the other correct answer: "Port 9100 is used for printing. Port numbers 9101 and 9102 are for parallel ports 2 and 3 on the three-port HP JetDirect external print servers." [To make use of this, at least in lprng, use the field :lp=<name_of_printer>%9100: where name_of_printer is a DNS name or IP address.] The advantage of printing to port 9100 rather than using the LPD facility is that the Unix host has more direct control of what gets sent to the actual print engine.

5. Joining a Samba Domain Remotely

17 Jan 2000 (15 posts) Archive Link: "samba-tng: Cannot create trust account as admin."

People: Greg DickieLuke Leighton

Greg Dickie reported a bug on samba-ntdom: "I seem to have domain admin. privileges and profiles are fine BUT if I want to join a workstation to the domain without using smbpasswd first (ie: just the NT dialog), it does not seem to work (it did in the old 2.1 code). It tells me my account does not have privilege. Any pointers to where I could start looking to debug this?"

Luke Leighton was puzzled, but had an idea. "try removing the workstation trust account from private/smbpasswd. check if it gets added, what the "flags" are set to. it if says "[DW ]", let me know, i think i may still have a bug, there." Greg reported that a new set of error messages, and the two of them debugged back and forth for a bit.

Luke finally saw what was happening. "you cannot just have any ordinary unix user modifying private/smbpasswd. the admin account you type in to the join-domain dialog must be mapped to root on the target box." Greg asked why he couldn't use the "admin users" setting in smb.conf, which is supposed to yield root privileges. Luke realized that he wasn't using this parameter for this purpose: "oops. well, it looks like it's only relevant to shares. and msrpc isn't shares, it's pipes :) that's my excuse, anyway :) it says file operations, and that doesn't include private/smbpasswd. honest!" Later, clearly not relishing the task of fixing up his code, he asked, "do you want me to see if i can sort it out?" No, said Greg: "REALLY not a big deal, I was just buggin ya, I'm sure there are better/more important things to do. I'm happy as long as there is a way to do it and there is... I'm happy! Now usrmgr.exe..."

6. Unix/NT User Mappings and Home Directories

17 Jan 2000 - 19 Jan 2000 (13 posts) Archive Link: "mapping from NT users to Unix users. question."

People: Luke LeightonSander StrikerSteve LangasekChris Tooley

Luke Leighton had an implementation question for samba-ntdom and samba-technical: "when giving out home directories, a user logs in as "NTuser" and gets mapped to "unixuser", i wonder if it's better to return \\server\unixuser as the home directory instead of \\server\ntuser. the reason is that it will make life a lot simpler when it comes to accessing smbd. i won't have to do any nt to unix mapping to create the [homes] section." He continued, "my question is, is this acceptable? do you, the administrators, mind if a user logs in as NTusername but actually gets told that their home directory is Unixusername? or, do you really want user logs in as NTusername and accesses their [homes] share as \\server\NTusername? which would you prefer?"

Predictably, the vote was split. Sander Striker apparently believes in the Principle of Least Surprise as it applies to end-users: "I guess I would prefer that if a user logs on he gets his NTUser home share. Otherwise people run to the administrator telling him there is somekind of security breach and that they can access someone else's files. ;-) You can't explain this behaviour to users... They just don't get it. It gets worse if you are confronted with new users every year. This is the case on a lot of universities and believe me, they're running Samba." Quite a few people agreed with him, one way or another.

Steve Langasek didn't see the problem. "Seems easy enough to explain to me: "The name of your home directory on the network has nothing to do with your username; it's not a security problem; don't worry about it." I also can't picture lots of users sounding the security alarms because their NT home directory isn't based off of their username. Most users, IMHO, are likely to a) not care, or b) be comfortable/familiar enough with NT to not be surprised by this sort of thing." He also offered a plausibly good reason to do it the other way: "The traditional value of the [homes] share, as I understand it, has been in providing an easy way to access the home directories of existing *unix* users. Using NT users instead would break backwards compatibility within Samba. Moreover, it sounds to me like using NT usernames for the [homes] share will add unneeded complexity to the code, which is a bad idea, IMO. :)" Lars Knesche agreed. [Editors probably shouldn't take sides in these things, but this one does. Why should any user assume that his home directory name must include his login name? Our mostly-Unix network here has a few hundred Unix users for whom this is not the case.]

Chris Tooley replied to Steve, "You and I obviously have very different types of users. My users would freak out if they saw something other than their username and the definitely know nothing at all about NT to assume anything."

Luke decided to go ahead and map the usernames so that NT users would see their own login names as home directory share names. However, he said, "doesn't really bother me, much, either way."

7. Explanation of NT SAM Aliases

17 Jan 2000 (2 posts) Archive Link: "NT Aliases"

People: Michael StockmanLuke Leighton

This was just a quick question-and-answer, but the answer was more than usually informative. Michael Stockman wondered what an alias is, in the context of the NT user database. He mused on samba-ntdom:

My theories:

  1. An alias is just another name for a user or group. It has got the same SID.
  2. An alias is another name for a user or group. It has a different SID, but the user settings are shared.
  3. An alias is a completely independent user or group. It has both different SID and different user settings. This would be consistent with someplace where I read that a alias is a local user on a domain server.

The ever-helpful Luke Leighton gave today's lecture on aliases:

understanding aliases is critical to understanding how to set up an NT domain, michael!

users:
users can be added to domain groups of their own domain and domain aliases of any domain.

groups:
groups can ONLY have user RIDs added to them, and by definition therefore they can only contain users of their own domain

aliases:
aliases can have ABSOLUTELY any SIDs added to them. the SIDs could in fact be total garbage, should you so choose. garbage SIDs, however, will have no meaning and are in fact a security risk in case someone finds a way to create the garbage SID, so don't do it!

to make it really clear, aliases can contain User, Group or other Alias SIDs from ABSOLUTELY any domain.

a user's groups can only be RID components. you can make a user be a member of domain group RIDs AND alias group RIDs, mixed. you can NOT make a user a member of a foriegn SID. select the 'Group Memberships' box on a user profile in USRMGR.EXE

8. New Shared Libraries

17 Jan 2000 - 22 Jan 2000 (60 posts) Archive Link: "[SAMBA-TNG] using and createing libsmb and libmsrpc"

People: Luke LeightonTim ColeElrondLonnie BorntraegerPhil Mayers

Luke Leighton posed this to samba-ntdom: "i have a question for you all. is it ok if i create a dynamic library, libsmb.so and libmsrpc.so?" Eight hours later, he made up his mind: "ok, i decided to go ahead with this. if you can't compile and you can program, please have a look at adding autoconf support for .a, using cvs main's autoconf as a base for ideas." Tim Cole suggested using libtool.

[Now, a shared library in Unix (also known as a shared object or SO) is like a Windows DLL, only better -- better in that on most Unix platforms, the SO mechanism allows for multiple incompatible library versions and late binding. SO's are typically composed of regular C code, compiled by a regular C compiler and linked by a regular linker, but unfortunately, the exact command syntax used to compile and link them is completely nonstandard; it seems that no two Unix vendors (except those which ship the GNU compiler tools) use the same syntax. Sometimes the procedures change between one OS release and the next -- this happened, for example, between AIX 4.1 and AIX 4.3. To make matters worse, different Unix brands have somewhat different feature sets with regard to binary formats; COFF-based, a.out-based and ELF-based shared libraries behave differently and in some cases must be built differently, and that is before getting into even-less-portable optimizations such as so_locations from Digital Unix and IRIX, or the two or three different types of shared libraries in recent versions of AIX....

Thus, with code like Samba, which supports many variants of Unix and a few other OSes as well, successfully building and using a shared library in all supported environments is tricky at best. Enter the free software package GNU libtool, whose sole purpose in life is to solve this problem by handling all aspects of building shared libraries, in a uniform manner, under as many operating systems as possible.]

Phil Mayers and Elrond had some discussion about one major disadvantage to using SO's: the possibility of interface changes, and of getting the libraries and the main programs out of sync with each other. Elrond mentioned symbol versioning, at which point Luke had to break in: "hey guys, you'll have to clue me in here, i have no idea what you're talking about!" Tim Cole explained, "Basically he's talking about different ways of handling binary compatibility across library versions. Among them, either keeping a consistent API, or using opaque structures, and passing the size/desired size to all functions that work with them."

Other bits of discussion branched out. More than one thread branch pondered the relative merits and demerits of the several different ways to resolve a shared library path: LD_LIBRARY_PATH, rpath, hard-coding the full pathname, or various runtime linker tricks. [Flamewars have been started over less. There exist some surprisingly strong opinions on these matters.] Another topic materialized about how to write reentrant code, not to be confused with thread-safe code.

Many other threads started popping up which related to the shared library effort -- mostly bug reports from users for whom it hadn't worked right. It gradually emerged that the libtool-based shared library setup needed some tweaking. Enter Elrond the Libtool Hacker. He sent Luke a few patches to make libtool behave better, and answered people's questions about various issues. He declared, "If I got all right, nobody should realy notice, that we ever switched to shared libraries." Lonnie Borntraeger was clearly overcome. "It's beautiful. I'm tearing up just thinking about how nicely it compiled, installed and ran. :)"

9. Misnamed Function?

19 Jan 2000 (6 posts) Archive Link: "safe_strcpy is unsafe"

People: Michael StockmanJeremy AllisonLuke LeightonChris Barron

Michael Stockman had an interesting observation: "safe_strcpy is not very safe. It seems that it writes 1 char longer than maxlen, which is bad if the buffer isn't that long." [This would seem to defeat the purpose of safe_strcpy(), which is to make sure that the string copy operation does not exceed a given length and cause a buffer overrun.]

Jeremy Allison explained: "Unfortunately safe_strcpy was designed to replace an interface that expected maxlen not to include the terminating zero (it explicitly says this in the interface definition). I am not happy about it, but it was designed to fit into the existing code (which was written to expect this property). It is safe given its interface definition, just not very intuitive. In the UNICODE Samba re-write I am fixing these bad assumptions."

Luke Leighton was equally unhappy. "does anyone want to write a perl or awk script that will +1 to every single usage of safe_strcpy() in all samba code? optimisations include removing -1+1. i just hate how safe_strcpy() has to use sizeof(str)-1 ABSOLUTELY everywhere." Jeremy commiserated: "Me too. It's just that you can't do this without examining every place this is used. That's why I didn't just make that change myself. It isn't that obvious as I recall."

One variation on Luke's idea came down the pipe: to make safe_strcpy() merely a macro. One way this could work (borrowing from Linux kernel coding, where they like using leading underscores to represent "lower-level" variations on a theme):

  #define safe_strcpy(d, s, n) _safe_strcpy(d, s, n+1)
  char *_safe_strcpy(char *, char *, size_t);

[

Don't blame me 'bout the vanishing waif / Don't blame me if your safe ain't safe, now, now.
--Chris Barron (of the Spin Doctors), "Laraby's Gang"]

10. LDAP Code To Be Maintained Again!

20 Jan 2000 (3 posts) Archive Link: "[SAMBA-TNG] watch out: new LDAP schema may be introduced soon"

People: Luke LeightonIgnacio Coupeau

Luke Leighton announced to samba-ntdom and samba-technical: "some kind person has volunteered to work on an NT5 compatible LDAP schema. that means that everyone currently using SAMBA-TNG's "development" schema is going to either be left behind or have to convert. i just wanted to warn you now before code starts to get committed." Ignacio Coupeau wondered, "A question, does the new schema runs with NT4? If not, what version/brach/date should I use for NT4?" Answer: yes, since NT4 does not support LDAP directly anyhow. This change only affects the communications between Samba and the LDAP server it authenticates against, and is only relevant to those running Samba as a PDC.

11. Inter-Daemon Interface Change

20 Jan 2000 - 21 Jan 2000 (11 posts) Archive Link: "CVS update: samba/source/msrpc (fwd)"

People: Luke LeightonNicolas Williams

Luke Leighton tracked down a race condition in the Samba logon process. Fixing the bug required a fairly major change in the communication between Samba daemons, so he forwarded the CVS log to samba-technical for dissection. His introduction: "god, this is a horrible one. if microsoft... never mind :) it's a design issue, and there's not much that can be done about it. sigh."

The CVS log entry itself explains: "the idea is that an individual process (smbd, for example) can do NETLOGON logins independently of another smbd process, without there being any conflicts in the NETLOGON credential database. the creds database key is now <(uint32)pid_t><workstation_name>\0<domain_name>\0. previously, it was just wksta/domain, and of course if two smbd processes did simultaneous NETLOGON logins, one of them overwrote the other's credentials because the database key was the same! oops!" He finished with a warning that the code in the main CVS branch had not been updated to work with the PID field, so it and SAMBA_TNG would not interoperate properly until further notice.

Nicolas Williams had a few ideas of what other bits information may need to be passed back and forth between daemons. He posted a list of these, which he and Luke then discussed for awhile. Finally Nicolas suggested indexing a tdb database with a key made up of a UID, vuid tuple, as that apparently makes all the necessary information available to all concerned parties. Luke replied, "*blink*. [various lights go on in luke's head. candles, if anyone's interested] i like it!" Then somehow they got around to the topic of a multithreaded daemon carrying out different RPC services in different threads. Luke was dead set against this idea:

uh... you _Are_ aware that DCE/RPC functions are exactly that: functions. and function calls can block for an _awfully_ long time.

if you start thinking in terms of "oh, we'll have one daemon and have it deal with multiple requests" then the consequences are that one user can trash several other user's requests.

and i Really don't want to consider doing an asynchronous implementation of the dce/rpc client and server code, in a similar fashion to how nmbd works. i know how nmbd works, i wrote the second implementation (and a third intermediate one that was never used, which pissed me off) and it took months to plan the data structures and two years to implement fully and three people to work on it.

so no, i don't want to go down this road. i'll make it as easy as i can for someone else to do this, but no, it's not one for me.

There is actually a FAQ entry for "Why isn't smbd multi-threaded?" The answer is roughly what Luke said here.

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.