Kernel Traffic
Latest | Archives | People | Topics
Wine
Latest | Archives | People | Topics
GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Samba Traffic #5 For 29 Dec 1999

By Peter Samuelson

Table Of Contents

Introduction

This was another Petty Threads week. The world does seem to be moving toward the Samba 3.0 release, but this is happening relatively quietly, at least on the five mailing lists we cover here. Andrew Tridgell just finished reinventing the flat key/value database library wheel, and Luke Leighton is still chopping up RPC code into little daemons. He and Tridge are still waging their smiley-laced flamewar over it, too. Such a peaceful time of year. Happy Y2K Meltdown, everybody!

Mailing List Stats For This Week

We looked at 357 posts in 702K.

There were 168 different contributors. 57 posted more than once. posted last week too.

The top posters of the week were:

1. Please Don't Crash the NT Servers

12 Dec 1999 - 21 Dec 1999 (9 posts) Archive Link: "Proposal: Good Neighbor Policy"

People: Dan KaminskyJeremy AllisonJohn MalmbergLuke LeightonSimon MurcottTimothy Cole

Dan Kaminsky led off: "I believe it is imperative that, in the coming developments of PDC functionality, a primary release objective needs to be that we not disable any network that a novice administrator incorrectly configures Samba within." He noted that Samba servers had been known to bring down NT-dominated networks through being misconfigured. This sort of thing would only grow more common, he said: "We haven't had to deal with this yet because our PDC support is (sadly/luckily) rather difficult to get working. Microsoft has dealt with this by making NT a holy terror to get functioning as a PDC at all, and an absolute impossibility to get to cease functioning as one." John Malmberg chipped in with an anecdote of a Samba server getting into a severe argument with an NT Server over the matter of browser elections, and concluded that, to be on the safe side, one shouldn't allow Samba to participate in browser elections. But, Jeremy Allison countered, "you can do this with a misconfigured NT server also." He continued that Samba was not in any way incompatible with NT in terms of browsing capabilities. John shrugged at that last: "Please understand that most of the people that ask me questions about this are also confused about simple things as subnet masks and default gateways. :-)" In the case of the election war, he said, "In this case if there was someway that SAMBA could have detect the deadlocked election, and drop out with the appropriate log message, no noticable problem would have been seen by the rest of the network." Luke Leighton didn't agree. "weelll.. that depends on whether someone configures it with "preferred master = yes" and also configures another LMB with pm=y as well!!! under these circumstances, the two will constantly fight it out every couple of minutes, generating masses of noise. the thing is that people tend to mess with the configurations not realising what kind of damage it can do, and there's really not much we can do about it if people really want to make samba brain-dead."

Simon Murcott testified about nmbd as a very capable master browser:

I am using samba 2.0.5a for browsing across a network of 40 solaris servers all interconnected via a WAN and it is SOLID. Each client on each section of the WAN sees that same list and it uses a pathetic amount of traffic to keep the browse lists in sync.

I have seen a pure NT solution in a slightly smaller environment which was incredibly ugly. The browse lists would constantly change (ie machines would appear and disappear at random). Plus the amount of traffic involved placed a significant load on the WAN.

All in all if you configure samba right you end up with an excelent solution for binding your network together.

If you let goons configure samba or an NT server then you are doomed from the start.

Finally, Timothy Cole thought the documentation needed some shoring up with regard to configuring the browsing functions. He didn't have time to do such a patch himself, but he gave a fairly detailed summary of various browsing issues.

2. More Daemon-Splitting, or "Breaking Up Is Hard To Do"

16 Dec 1999 - 21 Dec 1999 (19 posts) Archive Link: "Samba under Coherant and Macintosh"

People: Andrew TridgellLuke LeightonJean François MicouleauTimothy Cole

Andrew Tridgell, pausing for breath in the middle of a thread, posted: "I've moved this discussion to samba-techinical (we were making the mistake again of having technical discussions on the private team list). for those who don't know Luke and I are in a long debate on a proposed architecture change to Samba where things get far more split up into separate daemons etc. Its a friendly but "robust" discussion :)"

The topic du jour was Luke Leighton's implementation of msrpcd, the daemon he was splitting off smbd to handle Microsoft RPC requests, as opposed to file and print services, which would still be handled by smbd. Tridge had several issues. First, Luke's taking pains not to run msrpcd as the root user was wasted effort, he felt: "As I've mentioned several times, the msrpcd does not need to do user file access. With the exception of spoolssd it only ever accesses internal data structures. Internal data structures are NOT protected by your euid/uid. So jumping through the hoops of running as non-root just gives you a false sense of security - it gains you no real security." Second, he didn't like the whole idea of service control manager code (discussed at length in the last half of Issue #4, Section #1). Third, he didn't like where Luke was going with the nmbd code: "so we now have nmblookup connecting via a special protocol to nmb-agent. That opens up the possibility of something going wrong. It is a protocol and interaction between unprivileged and privileged code were none was before and none is needed. nmb-agent will need paranoid code to check for invalid requests, overflows, go-slow-attacks etc where right now we have nothing."

Regarding the third point above, Luke said: "let's have a look at the source code. god, it's so simple it's unbelievable. the "special protocol" is... there isn't one. there actually isn't one. [...] it's 60 lines of code, andrew." Later, he defended nmb-agent: "you're looking for reasons not to support nmb-agent, and those same reasons apply to nmbd [invalid requests, overflows, go-slow-attacks], therefore they don't apply." As to the first point, about root access, he said, "do you really, really want an anomymous user to run an msprc service as root? the answer, is a most definite, absolute no way. i just can't bring myself to not put in become_user() calls. i really can't."

Tridge attacked nmb-agent again: "As I explained to Luke on the phone this morning, there is a critical difference - nmbd uses SOCK_DGRAM whereas nmb-agent uses SOCK_STREAM. By using SOCK_STREAM you open yourself up to lots of these nasties. and, in case you wonder, just changing it to SOCK_DGRAM doesn't solve all your problems, it just adds different ones. also, nmbd has a pile of code to be paranoid about the format of packets. It carefully checks packets to make sure they are valid. nmb-agent doesn't do that. I think I've finally convinced Luke to drop nmb-agent." About root access for the RPC services: "The only other reason you seem to have is some mythical deep-seated notion that things run as non-root are magically secure. They aren't." He continued, "It is a common security misconception that running as non-root is always better - it is only better in some cases and this isn't one of them. I particularly want you to code this for running as root as it will hopefully make you more paranoid when writing the code. Your conviction that running as root is dangerous can be turned into an advantage that way."

There was a bit of back-and-forth on a few of these points, and the discussion took a turn for the technical. Luke started talking about writing a new function to validate a given security context without actually changing the Unix UID. "for each pipe, for each function, for each info level (and i believe that there is a basic mapping for these, i'll describe in a bit) you keep a hard-coded security descriptor. it's going to be a lot of work. there are well over a hundred locations where this function needs to be called, so i hope to automate the process somehow." Jean François Micouleau didn't think one needed to check this in hundreds of places: "You need only to check in the "open handle functions". NT will try the different info levels only if you allowed it to do so in the reply to the open handle function." Timothy Cole quickly corrected him, though: "Ehh, there's no guarantee that the client couldn't actually be something other than NT. You shouldn't really rely on the assumption that the client simply won't ask for things that it shouldn't have access to if you want any sort of security."

(ed. [] A server relying on a client to do its own security validation is almost always a bad idea. Various Windows NT services have been vulnerable to attack at some point due to such assumptions, and the NFS protocol is broken by design in this respect, causing some to refer to it as "No File Security".)

The discussion continued in various directions until, about eight posts later, it petered out.

3. DMB's vs. LMB's

19 Dec 1999 - 20 Dec 1999 (7 posts) Archive Link: "Domain-Master-Browser will not work!"

People: Richard SharpeLuke LeightonUsing Samba

Stephan Lauffer asked the world of samba-technical why the domain master browser (DMB) function of nmbd was not working. He posted annotated log file snippets. There was some confusion between a DMB and a local master browser (LMB), and Richard Sharpe elucidated:

The Domain Master Browser is not elected as such.

Under Windows, the PDC is the domain master browser, and it is usually the Local Master Browser as well, but this function is subject to elections.

Under Samba, the two functions are separate, and you use

  domain master = yes

to specify that Samba should be a Domain Master Browser, while a combination of OS level, local master and preferred master control whether or not Samba becomes the local master browser.

Luke Leighton clarified a little bit more: "specifically, dmb functionality is TOTALLY functionally separate from lmb functionality, to the extent where a dmb can LOSE local master browser elections on its own subnets and still perform its role, fully, as a dmb." This confused Stephan, who quoted the book Using Samba: "If you have a domain master browser in a subnet, a local master browser is not needed." Luke was to the point: "i hate it when this happens. it's not true." Then he reiterated his earlier point: "functionally, the two are totally separate. TYPICALLY, the two [DMB and LMB] are implemented on the same "host", in this case nmbd."

4. Security Concerns With Config File Location

20 Dec 1999 - 22 Dec 1999 (56 posts) Archive Link: "URGENT: REDHAT 6.1 STORES SAMBA PRIVATE FILES IN /etc"

People: Jeremy AllisonLuke LeightonMike Warfield

This is a followup to Issue #2, Section #3, where Luke Leighton warned the world about putting certain config files in a world-readable directory such as /etc. He had received network trace files that indicated that someone somewhere was doing this, rather than using .../samba/private/ as per the Samba default. The files with sensitive information in them are smbpasswd as well as any file ending in .mac. The Unix permission model has file-level granularity, so putting these files in a public directory is not a security threat per se, but Luke thought the use of /etc encouraged administrators to be sloppy with their permission management.

This week he discovered that at least one of the culprits was the packaging of Samba in Red Hat 6.1. He sent off an explanation to Red Hat Software with a CC to three of the Samba lists.

Jeremy Allison jumped in quickly. "Only stupid people will change these files to world readable. Stupid people shouldn't be admining systems :-)." Luke rejoined, "sum(0..n)(security)t tends to zero, as number of idiots tends to infinity."

Thereupon, two camps were formed: Luke's camp thought that having a directory named private was a good way to let admins know they needed to be careful messing with file permissions, and Jeremy's camp thought that the whole thing was not a security problem, and, although the private directory was not a bad idea, Luke was blowing it a little out of proportion.

One thing that really seemed to bother Luke was not so much that an admin could open up his own system to attack, but that the careless admin could open up his whole NT network to attack, since one can apparently use the information in these files to download the whole user database, including cleartext-equivalent passwords, for any domain of which the machine is a member.

The arguments went back and forth for two days or so. In the midst of the friendly fire, two additional facts came to light. First, it seems Mandrake has the same problem, if problem it be, and Caldera and Debian do not; the status of other binary-packaged releases is not known. Second, the problem actually stems from the original .spec file bundled with the generic Samba sources -- the .spec file was not written at Red Hat at all.

Many people called attention to the fact that other files in /etc -- such as /etc/shadow on many Linux systems -- should not be world-readable either. Mike Warfield was one such, and was also in the hey-everybody-calm-down camp: "Luke... Please consult with others before yelling "fire in the hole". Even I do that..." Later: "I don't see a problem with the configuration. If the consensus is to change it, then change it. But it is not a security problem any more than a lot more serious files in /etc, so let's stand down this firedrill." Luke did calm down considerably.

Finally, several people independently arrived at the same conclusion that Samba should act like some other security-related programs such as Sendmail: it seems recent versions of Sendmail check several files for sane permission bits, and refuse to run if all is not well. That way, a careless administrator will discover his mistake fairly quickly because Sendmail won't start.

5. Tridge's New Database Module

20 Dec 1999 - 23 Dec 1999 (7 posts) Archive Link: "new database code"

People: Andrew TridgellJohn Malmberg

Andrew Tridgell has been working on a new mini-database built in to Samba to handle certain data structures, and he posted an announcement to samba-technical that he had just committed the first bit of it to CVS: "For those who don't remember, the database code will be replacing a bunch of shared data structures and lock files that have been used in Samba previously. This should greatly simplify the internal structures in Samba and also has some external benefits. "

John Malmberg, the head honcho of the Samba VMS port, had several questions about design and implementation. "Is there a document that can be reviewed as the "public" interface to these routines such as in passdb? [...] This looks like a place where some platforms can introduce optimizations. [...] Is the "locking" library going away? If not, will it be changed to not reference routines in server.c? This kept me from converting it to a shared image."

(ed. [] He later clarified this last point: apparently in VMS, a shared library cannot have symbols that are resolved in the main executable using it. For anyone wondering why most Linux and FreeBSD distributions have switched the executable format from a.out to ELF -- or why the dynamic linker in AIX 4.3 suddenly grew a lot of complexity -- this is one of the reasons. a.out has the same limitation, whereas ELF and now AIX xcoff do not.)

As for documentation, Tridge pointed to the README file in the same directory as the implementation. And as for the locking library, he said, "all the old shmem locking code is gone. locking.c is has been extensively modified to use the new tdb code." As for platform-specific optimizations: "It should be pretty fast on most systems already. It will be slower on those without mmap(), but probably still acceptably fast." John brought up the possibility of using the VMS indexed file feature, where the OS has builtin database code. Tridge asked about indexed files: "does it handle arbitrary sized non-uniform records/keys and multiple simultaneous writers?" Yes, replied John: "Arbitrary sized non-uniform records: Yes up to 32,224 bytes/record. Arbitrary sized keys: Yes. and multiple levels of subkeys. Multiple simultaneous writers: Yes. Very scalable. Also tuning and analysis utilities are built into the OpenVMS operating system so that the file characteristics can be optimized for the particular load."

6. Small Threads

16 Dec 1999 - 21 Dec 1999 (18 posts) Archive Link: "(various)"

People: Timothy ColeMatthew GeddesDennis MorenoThomson PressGiulio OrseroJeremy AllisonPhil BurchOndrej HanakDave Reed

Finally, here are several of the more interesting odds 'n' ends from the tech-support portion of these mailing lists:

Thread: Win9x profiles
Problem: Ondrej Hanak wondered how to get Windows95 to store its user profiles in the [profiles] share.
Solution: Phil Burch and Mark Price both pointed at the Passwords Control Panel applet and its User Profiles tab.

Thread: Permissionproblem
Problem: Bernd Ganter had a question about granting himself the "delete" right on a Samba share.
Solution: Timothy Cole explained Unix semantics for this sort of thing: "The ACLs you see are actually "native" Unix permissions. [...] This means that to delete (unlink) a file or directory, the only requirement is that you have write permission on the directory that contains it -- there is no delete permission as such."

Thread: Moving from NT PDC to Samba PDC
Problem: Paolo Supino wanted to upgrade his NT-based PDC to a Samba server and had some questions about how to go about it doing the least possible disruption to his network at large.
Solution: Matthew Geddes recommended using Samba 2.0.5a rather than the 1.9.18 branch which came installed with Paolo's Red Hat Linux 5.0. He then explained that things like User Manager wouldn't work with Samba. As for actually migrating the setup: "You can bring up Samba in the old Domain. Make sure that the NT PDC isn't running as a PDC at the time though (switching off the netlogon and browser service should be enough). You can even keep your old accounts and passwords by using pwdump.exe. It grabs the encrypted passwords from the SAM database and saves them in a file the same format as smbpasswd. I am looking at having our PDC become a Linux box and the testing I have done so far looks promising. You will need to re-install NT in order to make it join another Domain (instead of controlling it). Hopefully they will fix this soon (actually, I'm not really bothered, because you need to do the same to put Linux on the machine ;-))."

Thread: NT client setup
Problem: Subba Rao wanted to set up a Unix box to print to an NT printer.
Solution: Giulio Orsero pointed him at the smbprint sample shell script that comes with Samba.

Thread: Samba performance on FreeBSD
Problem: Martin Welk discovered that following socket options in smb.conf made Samba on FreeBSD much faster:
socket options = IPTOS_LOWDELAY TCP_NODELAY SO_SNDBUF=262144 SO_RCVBUF=262144
He was a little suspicious, though, that this wasn't already the default. Was there a catch?
Solution: Dan O'Connor's experience was that Samba on FreeBSD had recently sped up noticeably: Samba 2.0.6 on FreeBSD 3.4-STABLE was much better than before. He suggested trying "the latest", and also recommended investigating soft updates to speed up filesystem performance in general. (Soft updates are a scheme pioneered by the FreeBSD team in which disk writes are ordered such that in the event of a crash or power failure, the data structures on the disk will never be corrupted beyond repair. The intent is to achieve the safety of a journalled filesystem without most of the inefficiency.)

Martin, it happens, was already using soft updates....

Thread: 2.0.6/Sol. 251/NTW4 - Drive mapping anomaly
Problem: Dennis Moreno had an interesting encounter with NT4 Service Pack 6 to share: "When I first connect to the Samba server, I run a logon script that maps 5 shares to drives F,G,H,L,M. Some time later, when I check "My Computer", I find that the share mapped to H: has been mapped to all the remaining drive letters as well! For example, after I mount /users on G: and /programs on H:, I'll notice at some point later that I also have /programs mapped to I,J,K,L,M and so on through Z."
Solution: Mike Robinson and Chuck Smith had both seen the same thing, again with Service Pack 6. Chuck worked around it by just Not Doing ThatTM: instead of mapping drives in a logon script, he manually mapped them with the "persistent" flag on.

Thread: Very basic SAMBA setup?
Problem: Steve Salazar thought the Samba documentation aimed too high; all he wanted was a very simple home-networking setup, no passwords or anything.
Solution: Dave Reed posted a simple smb.conf snippet.

Thread: SAMBA connectivity
Problem: Someone at an outfit called Thomson Press had a rather brusque question: "We have started to build linux server. We are trying to connect the client with sama options. Can any one please provide us the complete procedure of samba configuration in Linux server. Expecting replies at the earliest."
Solution: Strangely enough, considering the tone of the question, nobody seemed to think they owed Thomson an answer.

Thread: why smbpasswd cannot delete users?
Problem: Giulio Orsero asked, "There are no smbpasswd's command line switches to delete an account in the smbpasswd database, so that I have to delete them by hand. Is it intentional? If it is, why?"
Solution: Jeremy Allison had good news for him. "Nope. Someone has submitted a patch for this that was too late to integrate into 2.0.6. I'm going to get it in before the next release."

 

 

 

 

 

 

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.