Table Of Contents
|1.||2 Feb 2000 - 8 Feb 2000||(65 posts)||The Rise and Fall of a Crypto Proposal|
|2.||3 Feb 2000 - 8 Feb 2000||(28 posts)||The Quota Problem Again|
|3.||5 Feb 2000 - 8 Feb 2000||(21 posts)||Automatic Line-Ending Conversion?|
|4.||6 Feb 2000 - 10 Feb 2000||(13 posts)||The Microsoft Kerberos Implementation|
|5.||7 Feb 2000||(8 posts)||Another GPL Violation?|
|6.||7 Feb 2000||(4 posts)||Setting System Time on NT|
|7.||8 Feb 2000 - 10 Feb 2000||(115 posts)||The Amazing, All-Purpose Thread!|
|8.||8 Feb 2000||(9 posts)||Browsing Semantics, and BDC Auto-Updating|
|9.||9 Feb 2000||(8 posts)||How to Share Netscape Profiles, Cross-Platform|
|10.||11 Feb 2000||(14 posts)||Another Simultaneous-Multi-Domain Question|
This week was more or less your typical Samba hacking week. Last
week's flurry of RPC function interface changes in the
SAMBA_TNG branch have settled down and Luke is now working
on the password database backends. While doing this, he came up with
the New Idea of the Week, a password encryption function that has
proved to be somewhat controversial -- not the function itself, really,
but the idea of using one. The arguments flared up quickly but seem to
have died down just as quickly.
Other happenings this week include more bug-stomping in preparation for Samba 2.0.7. Jeremy wants to put out at least one more pre-patch before the real thing, but the quirks that showed up in the first pre-patch seem to be getting ironed out with some dispatch.
Mailing List Stats For This Week
We looked at 643 posts in 1322K.
There were 210 different contributors. 80 posted more than once. 55 posted last week too.
The top posters of the week were:
1. The Rise and Fall of a Crypto Proposal
2 Feb 2000 - 8 Feb 2000 (65 posts) Archive Link: "SYSKEY2. Request For Comments"
People: Jeremy Allison, Luke Leighton, Mike Warfield, Seth Vidal, Phil Mayers,
Luke Leighton needed a password encryption function. He wanted to
be able to encrypt a Microsoft LanManager password hash, which itself
is a rather weakly encrypted password. (And, in fact, for all intents
and purposes the LanManager hash is plaintext-equivalent, thanks to
wire protocols that only challenge the client's knowledge of the hash
itself.) He wanted this new 'n' improved function so that he could
store passwords in a publicly-readable file, but didn't want to
duplicate Microsoft's mistakes. So he wrote up a proposal based on MD5
and a secret key, and asked
samba-ntdom how it looked,
security-wise. (MD5, invented at RSA, is a one-way encryption hash
function. It is widely used for such varied tasks as checksums of
network-distributed files, password hashing on some Unix systems, and
random-number generation in the Linux kernel.) Ironically enough, for
such a long thread, nobody commented on the security of the proposed
Jeremy Allison asked the obvious question: "Why ? SYSKEY is a silly idea ! Either you trust root, or you don't. If you don't trust root, then all the SYSKEY in the world doesn't help. If you do trust root, then why not let them see the hashed passwords ?" Later: "Luke - just because NT does it doesn't mean it is a good idea. Don't code this up. If you do it'll be a waste of your efforts as it will not go into a stable release." Phil Mayers was just as skeptical.
Luke was ready with an answer: "think. ldap. sql. nis+. we can't trust them, and they're all publicly accessible network protocols." In other words, in order to store Samba passwords using various methods including directory services, they would need to be encrypted, since the underlying protocols are not considered secure.
Jeremy was emphatic. "IT IS NOT OUR JOB TO FIX THESE PROTOCOLS !!!!!! We are NOT responsible for fixing LDAP or NIS. When they add session based encryption we will be secure. Stop trying to solve other peoples problems in Samba. It is NOT our job."
Someone used the phrase "fixing NT" in connection with Samba, and there followed a bit of digression concerning the semantics of fixing versus replacing versus whatever. Mike Warfield put it well: "No offense, but that interpretation sounds like you would call purchasing a Porshe to be a fix for a Ford. I won't disagree with your view..."
Back on topic, Luke and Jeremy continued to battle it out. Luke: "sorry ppl, fed up with arguing and explaining this, my hands are now constantly hurting. i'm creating a syskey2, it's going in the source code, if you don't like it, jeremy, well, work it out for yourself as to why it's needed." Jeremy: "Luke, this is not going into the shipping source, for reasons I have already explained. This is why I don't like you running off in a branch. This is why your branches get abandoned. You have not demonstrated a need for this, you have not demonstrated how it improves security in any way. You are just adding this as NT does it. This is not a good enough reason." Jeremy again: "Bringing up LDAP and NIS+ as a justification for SYSKEY is not valid, as therse protocols are better secured in other ways (transport level security) than a hack in Samba. I have a 'stupid SMB security tricks' talk that covers this in more detail (if you get to attend a talk I do you can hear part of it :-)." Luke:
well, i don't trust administrators to do a decent job (read the README on security, or go to a security talk), so i'd like to add a mechanism that will make me not wince when i see this kind of message: hi, my name is joe, and i'm setting up samba with ldap. i just wanted to check that my schema is right. please could you review it for me, thank you:
"When I'm back in the USA
I'll call him and we'll agree. That's what usually happens. You're
just seeing the public face of Open Source technical discussions. Like
making Law, and sausage, it's not always pleasant to watch :-). But
it'll turn out ok, honest :-)."
Luke, responding to the charge
that SYSKEY2 is unnecessary since the admins should just Know Better
Than To Do That:
"in this case, i'd still
like samba admins to be able to use these protocols, without even
having to KNOW that their passwords are protected over-the-wire. i.e
if they didn't read the damn documentation, they still don't get
screwed over, and we don't end up with a report on bugtraq."
Luke, later explaining that he was not just trying to redo
Microsoft's SYSKEY security:
places where microsoft messed up with rc4 that i can think of in under
NetrSamSync - info levels 0x23 and 0x24
tick... tick... tick... damn, there's one more, i know it...
.. sure there's another. anyway, you get the picture? i'm not about to bother with somestupid algorithm if i didn't think it was necessarey, yes?"
Then, in an abrupt change of pace, Jeremy posted:
"You are correct though, that I'm trying to keep current on
SAMBA_TNG and with the rate of change it's very hard at the moment. I
hope that to get easier soon(hint hint :-) :-)."
thought maybe he could read between the lines:
"For whatever reason I think you're trying to hint at maybe a
code freeze of some type. If this is the case I'd love to see
it. Keeping up with the CVS is not very easy for me right now."
There was a deafening consensus for a code freeze for Luke's
SAMBA_TNG branch -- perhaps surprisingly, Luke was part of
it. Well, sort of:
"except for the
as i'm still not done with these. .. *thinks* ... i'd like to
msrpc/msrpc*.c in that, as well, because..."
So everyone agrees on a code freeze for
Even Luke. But, as Jeremy pointed out:
"Unfortunately Luke is the one who has to stop adding new code
and do the freeze before we can look at the merge :-). How about it
Luke ? Don't say yes please, just stop adding new code :-)."
2. The Quota Problem Again
3 Feb 2000 - 8 Feb 2000 (28 posts) Archive Link: "preallocated file size"
People: Terry McCoy, Maulik Desai, Jeremy Allison, Nico Williams, Dave Collier-Brown, , Richard Sharpe
The same disk quota "bug" discussed last week in Section #7 (sm20000210_11.html#7)
came up again.
Terry McCoy speculated
"While the copy is in progress an listing of the destination
directory on the Samba server shows that the file is in the directory
with the allocated size of 1.9GB. It would appear that perhaps the
file is being created and a seek ahead is being done, then the process
of coping the file over from the client to the server is begun. Hence
a method to preallocate disk space for the new file."
to know why, and whether you could turn this behavior off.
Maulik Desai piped up: "When I used explorer to write a file on samba server (drag & drop) and canceled it before it was completely written, the (corrupt) file still existed in the directory instead of being deleted. It appears that NT handles this correctly by deleting the file if it was canceled before completely written." Was this a Samba bug? Yes, Jeremy Allison answered, if NT handles this case correctly and Samba doesn't. The latter assertion was never really demonstrated during the thread, however.
Richard Sharpe and Dave Collier-Brown went looking for this bug, whether it be client-side or server-side, and concluded that it is an NT-only optimization (Windows95, at least, did not do it). One prevailing theory is that the NT Explorer does this in order to know immediately whether or not a file will fit on a filesystem, so the user won't have to wait for a partial copy that will ultimately be unsuccessful.
Talk turned to how Samba should work around NT's behavior (see last week's coverage (sm20000210_11.html#7) for exactly how this "optimization" can mess things up). Jeremy Allison explained, "The client is expliticly setting the file size, then one of the writes into the file is failing (probably with ENOSPC). Now what should Samba do here ? The client explicitly told us what file size to set. Do we then override that and deliberately truncate the file on write fail ? Should we do this ? Opinions please."
Nico Williams had the idea of preventing Samba from creating sparse files in the first place. "The impact on performance would not be nice though," he noted. Dave Collier-Brown thought about trying to check disk space when a file was extended, to anticipate disk-full errors, but Nico Williams pointed out that there was a nice race condition there: the filesystem might fill up between the time Samba checked and the time Samba tried to use it, so this bug would not entirely go away. His next idea was to truncate the file in question when it filled up the disk without being fully written to, so that its size would not be deceptively large.
Luis Claudio Goncalves, at this point, posted a small patch to implement the truncate alternative. It generated a bit of discussion, including a rehash of what Unix sparse file semantics really were. (One gets the feeling, from this whole thread, that many Samba list regulars do not really understand how sparse files work. This is not surprising. Even many longtime Unix users only vaguely know about sparse files. The feature seems to be unique to Unix-like OSes, just like the concept of a setuid bit.)
3. Automatic Line-Ending Conversion?
5 Feb 2000 - 8 Feb 2000 (21 posts) Archive Link: "Using NT registry calls to solve CR-LF issue with text files."
People: John Malmberg, Beau Kuiper, Tim Cole, Luke Leighton, Gunnar Degnbol,
Any old Unix hand will know all about line endings. MS-DOS text
files are supposed to end their lines with the two ASCII characters CR
and LF, whereas Unix text files usually just end lines with LF. Mac
OS, like the earliest Apple II DOS before it, simply uses CR. Any user
of a system that supports file access to/from multiple platforms will
run into this incompatibility sooner or later; usually, text files must
be converted manually from one format to another, since it is difficult
for a computer to divine what is or isn't a "text file", as opposed to
a binary file which must not be tampered with. Periodically, the issue
comes up on the Samba lists of how to convert text files to and from
the MS-DOS line-ending standard. One standard answer: on Windows, just
WORDPAD instead of
WORDPAD can work with Unix-style text files. Another
common answer: use a preexec script to convert all the files in a share
whenever a client mounts the share.
And it came to pass that John Malmberg had an idea, and he spake unto samba-technical, saying: "With the registry calls that you can do now, is it possible or practical to look up the file type in HKEY_CLASSES_ROOT before it is transferred, and if it is registered as a known text type to translate the CR-LF information as the file is being transferred? Just a thought."
Beau Kuiper protested: "A very evil thought. They tried to do that with the linux msdos filesystem support. It really stuffed life up for many people with scilent data corruption. To do the same with samba would be not to learn from the mistakes of others. to be specific: YOU CAN NEVER DETERMINE WHAT IS STORED IN A FILE GIVEN THE NAME OF THE FILE :-)"
John was not deterred. "Windows actually uses two methods of determining a file type. The first is a registry, and the second is to examine the first two bytes of the file for a signature. Some programs use the signature over the file type. Somewhere there is a list of these magic codes, but I can not recall where it is at the moment." He continued, "It would certainly be evil if it was manditory, but it could be very useful as a per-share option." Finally, "Remember the average user thinks all this stuff works by magic." Tim Cole replied, to that last: "/etc/magic_/index__*evil_grin*_.html"
As to the two ways to identify a file, Beau was impressed. "I learn new stuff every day :-). I never knew windows used a second way to identify files." Luke Leighton knew something about it: "it's the storage / streams - structured file storage system. if you have access to the MSDN, look up the CStream and CStorage classes in the MFC source code, and go from there." Presumably this is that infrastructure which is supposed to make efficient use of the NTFS feature of multiple forks per file (like Mac OS, only an arbitrary number of them). Gunnar Degnbol also had some tidbits to add:
I have looked at how Windows determines MIME types. The url is http://msdn.microsoft.com/workshop/networking/moniker/overview/appendix_a.asp.
It can be done using
FindMimeFromData(), but it won't
work. If the MIME type can't be determined more precisely than
text/plain' (after considering the type reported by a
web server, magic bytes, whether the data looks like a binary or
text, and the extension), and the file is associated with an
application, the type is set to
application/octet-stream'. So, for example, a
.C file will not be reported as a text file if you have
a C++ compiler. Nothing in the registry indicates that it is a text
The reasoning behind this behaviour is amazing:
"As an example, this is necessary when downloading, among others,
cmd files, which are plain text
files, are frequently identified by the server as
text/plain', and have no associated MIME type in the
registry. Without the final check for an associated application,
these would be displayed in-pane, whereas the desired behavior is to
launch the command interpreter."
The Internet is just like your hard disk, or your LAN, so when you
click on a
.BAT file in your integrated file
manager/browser you will obviously want to run it before reading it.
I guess this has been fixed many times over (once for each dangerous file type).
Gunnar had a nice parting shot, too: "The average user should not be led to believe it is possible to successfully ignore how computers work."
4. The Microsoft Kerberos Implementation
6 Feb 2000 - 10 Feb 2000 (13 posts) Archive Link: "Win2k & Samba compatibility?"
People: Steve Langasek, Jeremy Allison, Terry McCoy, Chris Hertel, Luke Howard,
Steve Langasek was trying to get information from
samba-technical about Samba compatibility with Windows
2000. Among other things, he wondered:
remember catching something last month about Win2k running in "NT4
compatibility mode". Is this still required for domain logins? What
about Kerberos 5 support--are we likely to see that in Samba any time
Jeremy Allison had a quick answer: "Well, I intend to add kerb5 support as soon as we get significant user demand for it. I'm trying not to get onto the Microsoft treadmill of adding new stuff to keep up with Windows - that way lies an endless sprint to keep up :-). I expect to get demand for kerb5 as it's such an improved authentication method - but not for a few months yet."
Terry McCoy thought it was easy. "Adding support for kerb5 on platforms that support PAM should actually be just a few lines as long as the machine's PAM configuration is working. We are using Samba (on Solaris 2.6) as an gateway to our AFS file space. By using PAM we are able to compile Samba without having to link in the AFS libraries from Transarc that would be required to do authenticate with AFS's KDC. Instead we just link with --with-pam option." He posted the very minimal changes they had had to make to Samba to get this working.
Several people pointed out that what Terry was doing was quite different from interacting with Windows 2000 Kerberos. He was just authenticating a normal NT client (using unencrypted passwords) with a Kerberos server, whereas what was needed was to accept Kerberos authentication credentials directly from the NT5 client and pass them on to the Kerberos server. Chris Hertel explained even further:
Microsoft is using a proprietary Privilage Authorization Certificate. Note the word "Authorization". Kerberos was originally designed as an Authentication service. PACs were added as an option for K5. Microsoft has (last I heard) chosen not to release info about their PACs.
The upshot is that many, many systems will have trouble. I heard an MBONE multicast of a Q&A session with Vixie the other night. He was explaining that in certain configurations a W2K box will expect to use it's PAC as authoriziation for DynDNS registrations. Of course, a non-W2K DNS server won't recognize the encrypted, proprietary PAC and will drop the request on the floor, logging an unauthorized registration request.
The result will be that the DNS server will be filtering out large numbers (depending upon the network size and number of W2K boxes) of such packets and the W2K boxes won't be getting thier names registred. Instant DoS.
Steve's reaction: "So... how much work goes into figuring out an undocumented PAC?"
Luke Howard replied: "Assar Westerlund, author of Heimdal (a freely available Kerberos V implementation) has done some work decoding the PACs. See the notes in the Heimdal distribution and/or Kerberos mailing list archives." URL, please? Several people knew that one: http://www.pdc.kth.se/heimdal/ and http://www.padl.com/~lukeh/heimdal/ were mentioned.
5. Another GPL Violation?
7 Feb 2000 (8 posts) Archive Link: "samba in vmware?"
People: Greg Dickie, Greg Leblanc, Luke Leighton, VMWare, Andrew Tridgell,
Greg Dickie posted the following information to
"I just downloaded
vmware 2.0beta for linux and it "looks like" they are packaging samba
in with it to provide connectibility between the host and guest
OSes. Was anybody aware of this? Does anybody care? I guess its not a
Greg Leblanc explained: "If you bother to read the help that 2.0beta provides when you run vmware-config.pl <grin>, you'll notice that it suggests that you DON'T allow it to set up samba if you already have it running. From the looks of the files that shipped with my VMware install, it doesn't actually include Samba, but probably checks to see if you have samba, and then volunteers to configure it. I heard that VMware has donated a handful (bunch?) of VMware licenses to the Samba gurus so that they can test NT-samba connectivity without so many PeeCees floating around, or so many reboots."
In another message: "I also don't see any documentation/license information for samba. I think I'll take this up with somebody at vmware unless somebody ojbects..." Luke Leighton jumped in: "yes please. samba should ALWAYS be provided with a copy of the GPL license. they are in violation of the GPL license, otherwise."
Greg Leblanc posted back not long after, forwarding a message from the VMWare people (http://samba.org/listproc/samba-ntdom/February2000/0227.html) . They had written: "Yes, we are shipping a version of samba with VMware. Although it is not available yet on our web site, we are going to have a technote page that describes the filesystem integration using samba, and includes a link to the source diffs. These source diffs are very small and we are hoping that the maintainer of samba and copyright owner, Andrew Tridgell, will incorporate them soon." Later: "Andrew is aware of the project and very supportive of it. I specifically asked him if he wanted a copyright banner displayed as part of the installation, but he declined."
For some reason VMWare chose not to explain why they were shipping Samba without a copy of the GNU General Public License. As Luke said, this would appear to be a license violation.
6. Setting System Time on NT
7 Feb 2000 (4 posts) Archive Link: "Trying to do net time /set from logon script"
People: Richard Sharpe, David Bannon, Andreas Krogh,
This was one of those delightful threadlets with a list-defying
signal-to-noise ratio. Richard Sharpe had this query for
"I am trying to do
net time \\server /set /yes from a
logon scipt that runs from an NT 4.0 WS machine that has joined a Samba
2.0.6 domain. NTW complains that the user does not have a required
There were three responses:
GRANT.EXE (http://www.franzo.co.nz/hansson/grant.htm)by Andreas Hansson, which gives users specific privileges.
k:\util\grant add SeSystemtimePrivilege everyone
Now how often do you see that? Three responses, three completely different approaches to solve the same problem. All signal, no noise. It was beautiful. Your editor was deeply moved. (:
7. The Amazing, All-Purpose Thread!
8 Feb 2000 - 10 Feb 2000 (115 posts) Archive Link: "SYSKEY, TNG freeze, 2.0.x->TNG merge and other thoughts"
People: Nico Williams, Charles Owens, Luke Howard, Luke Leighton, Jean-François Micouleau, John Koyle, Jeremy Allison, Andrew Tridgell, Todd Sabin,
This thread, the 363-kg gorilla of the week, touched on life, the universe, and everything (not necessarily in that order). Nico Williams started it by just posting "just a view from the sidelines" on a few current issues. He thought the proposed TNG code freeze should wait a few weeks; he thought the SYSKEY2 proposal was a good one thanks to the necessity of supporting legacy directory services without strong session encryption. He also thought the merge of TNG features into the stable Samba code base should be pretty easy: just cut 'n' paste certain subsystems, particularly RPC. He finished with the mildly provocative "I think it's safe to say that TNG is so jam-packed with good ideas that it will become the next Samba."
Clearly there was plenty of fodder there for lots of healthy discussion (or flame-warmongering, if one prefers). An image is called to mind of tossing a short treatise on the Five Points of Calvinism into an inter-faith prayer breakfast. It actually wasn't that bad, but one could say Nico's post was a good conversation piece....
Charles Owens was impatient for the new LDAP schema support: "Is there any update available as to when Luke Howard's SAM-via-LDAP-with-win2k-schema will make into the codebase (either TNG or TNG-post-merge) ? Getting a somewhat finalized schema in place seems to me to be a critical milestone for obvious reasons. I need to roll out some more implementations and would much prefer to use the new schema (as would everyone I'm sure ;-)." So Luke Howard gave a status report: "Only the nt5ldap passdb stuff is anywhere near complete. The nt5samrldap stuff is just not done. That's really tricky, and I need to get some serious time to work on that again, and I'm busy the next couple of weeks." Luke Leighton, meanwhile, said of the code: "it's experimental and subject to change."
Jean-François Micouleau disagreed with Nico's suggestion to delay freezing TNG: "NO. freeze Now ! I know Luke well enough to say that if you leave him just a week, he will have a new idea he'll want to code." He also thought Nico was severely oversimplifying the TNG->production merge: "totally unrealistic. You know why ? Because I've done it. And give up. And felt some much depressed than I was close to install win95 on my machines. Merging TNG in HEAD is not much realistic. I also tried, still have a tar.gz of the result somewhere. The only viable path is to extract features of TNG in diff files and incorporate by hand in HEAD." John Koyle agreed about the freeze: "I agree, I've spent about the last 2 weeks just trying to get TNG setup and working properly against an LDAP backend. I've done so many cvs updates my head is spinning. Code compiles then doesn't, etc. Finally, I got it working [...] The point is new people like myself (to TNG) would very much like to test/debug TNG, and it's nearly impossible to do that when there are 30 cvs updates per day." At this point, Luke Leighton made an astonishing statement: "*sigh*. ok, i promise i won't do anything more than bug-fixes, samrtdbd and libsurs work." Was he serious? Luke Leighton?
Nico asked Luke at one point, "Why are you so willing to code up SYSKEY, which we all agree is only necessary for some SAM backend implementations, AND YET you don't want to code up an ACL system that's more reusable than SYSKEY??" Luke's reply: "SYSKEY is 4 lines of code and maybe 10 or 15in strategic place to use it to secure all not, some, SAM impls. an ACL system is an indeterminate number of lines, used in an estimated 100 to 150 places."
Luke L. and Jeremy Allison had some exchange concerning how to merge code between branches. Luke hates the 2.0.x RPC code -- doesn't want to ever see any of it in any future release branch. Jeremy pointed out that there have been quite a few fixes that have gone into the 2.0 branch that Luke's TNG branch hasn't got, and that there are a few things the 2.0 RPC codebase actually does better than the TNG codebase. That sent Luke on a mission: he did some CVS checkouts and diffs, to determine what all has been committed to the 2.0 RPC code that he didn't have in his own branch. Over the course of several messages he analyzed each changed file in terms of what it did better or worse than his own code -- the goal being to eventually be able to debunk Jeremy's claim that the 2.0 code has any continued raison d'être.
Without more than passing familiarity with Microsoft RPC and Samba's implementation thereof, it is impossible to really follow Luke's journey through the CVS archives, but in summary, he seems to have found a few diamonds here and there that he can use; for the most part, though, he dismissed the 2.0 code as obsolete and broken.
Jeremy didn't think he and Luke were talking about the same bits of code at all. "I'm not talking about the functions you are referring to at all. I know the code that implements these in TNG is better and should be used (once reviewed). I am talking about the whole underlying substrate of the rpc_parse stuff, and the way the 2.0.x code handles the PDUs and buffers for the RPC packets. It is this code that is more advanced in 2.0.x, not the server functions." Jean-François apparently agreed. Luke looked again, and saw Jeremy's point. However, he said, "you trust that code and think it's more advanced, because you wrote it, and understand it." Which is hard to argue with, so Jeremy didn't. Instead, he replied: "Well don't get too upset. You want someone to look at your code and review it, and if you've implemented this functionality in a stable mannor, I'd love nothing better than to drop your code right in. I won't do that without looking at it however (which is what I thought you wanted :-)."
Moving on. Luke reaffirmed one reason to have his SYSKEY2 support: "private/smbpasswd can be made world-readable. sounds weird, neh? WAIT - hear me out, before shooting mouths and telling me it's a stupid idea." He elaborated: this way a lot of code wouldn't have to run as root any more. Insert standard run-as-root-or-don't-run-as-root exchange here (see the end of Issue #4, Section #5 (sm19991223_4.html#5) -- Andrew Tridgell, for one, believes that Luke puts much too much stock in avoiding running things as root). Nico was blunt: "Trust me: the SAM RPC daemon should always run as root." In other posts he reiterated: "We've already settled that point by having SMBD pass in PID/VUID information with the DCE/RPC calls and storing the user context info in a TDB keyed by PID/VUID. Why rehash this? So the MSRPC daemons will have access to the user context information. They have to implement authorization functionality internally because the objects which most of those MSRPC daemons deal with are NOT Unix kernel objects (files, pipes, Unix sockets, processes, whatever); if those objects are not Unix kernel objects then switching Unix security contexts (euid/egid) HAS NO EFFECT." Andrew Tridgell posted a nice summary of the issue from this same point of view:
We have to decouple the unix security context from the RPC security context. We have the SMB and Unix security contexts coupled in smbd, but we get away with that because we are dealing with objects that the unix kernel knows about so the unix security handling does all the work for us. In msrpcd the situation is quite different as we are manipulating objects that have no parallel in the unix world - so we must not couple the security contexts or we end up relying on protection that the kernel just can't provide.
In NT things are different. There they have the objects in the kernel and the kernel knows how to protect them. The NT kernel security context provides protection of the objects manipulated by msrpc calls so there is no issues as to whether these two contexts should be coupled - they are the same thing. On non-NT systems we must design things quite differently.
Think about the above couple of points carefully Luke. They are central to what you are working on.
Luke's response to most of the above: "because i am not thinking in terms of just NT, here, any more. i'm thinking in terms of a proper dce/rpc full implementation. except, without the thread library, for now." He also said, "if you're suggesting that just because some msrpc service implementations should, in your opinion (and a few others), be run as root, that the entire MSRPC service-running-system must run all services as root, then i have to say, that's silly."
Predictably, this stuff went on for quite awhile. Between Tridge,
Nico and a few more supporters that came out of the woodwork, these
points were duly made over and over again. One refreshing diversion
concerned the NT implimentation of password authentication. Todd Sabin
informed the world:
"Actually, it's not
implemented at kernel level. The
\winreg server is
winlogon.exe. Unfortunately, if
winlogon.exe exits for some reason (like, umm, someone
crashing it), the kernel notices it and actually forces a blue
In another post:
observe this empirically by crashing
interactively. They've been making it harder for power users to do it
(gee, I wonder why? :)), but something that has always worked is
attaching a debugger to it, and then closing the debugger. That
terminates the debuggee."
Oh, and while we're on the subject of weaknesses in Microsoft
software, Luke Leighton posted a nice tidbit:
"actually, if you add a BDC to a domain using NT4, you can use
rpcclient's samsync command to pretend to be that BDC because the trust
account password is BDCNAMEUNICODELOWERCASE, and grab the entire SAM
database anonymously. the window of opportunity is between when the
BDC is added to the domain during the BDC-install stage and when the
BDC installation is compelted and yuou are presented , for the first
time, with the
ctrl-alt-delete box on the BDC. so yes,
microsoft allows anonymous users to download the passwords, but not in
the way you perceive or describe. the word from microsoft is that
microsoft does not consider this to be a serious security risk, by the
way. oh, and they've probably fixed it for nt5."
Concerning RPC security contexts, nothing concrete came out of all this.
8. Browsing Semantics, and BDC Auto-Updating
8 Feb 2000 (9 posts) Archive Link: "Browsing and stuff"
People: Richard Sharpe, Matthew Geddes, Greg Leblanc, Luke Leighton,
Matthew Geddes had two Samba servers running, and wanted to use them
for redundant browse masters. He posted a summary of his configuration
samba-ntdom: both machines were using the parameters
os level = 65 domain master = yes local master = yes preferred master = yes
except the second had
os level = 60. He
asked if the second machine would force (and win) a browser election
assuming the first one went down.
Richard Sharpe answered the question:
No, it will not necessarily force an election. The things that will cause an election are:
You have not necessarily configured it wrong, but you do not need the preferred master on the second server, as that just forces it to have an election when it comes up, which is useless if the other one is running, I think.
Matthew's other question was about backup domain controller functionality: "does Samba BDC pass all authrentication on to the PDC, or does it cache or store a copy of the SAM?" The latter, answered Richard.
Greg Leblanc added:
"I don't know exactly
how samba does it, but NT propogates (sp?) changes to the SAM at
regular intervals. I think you can even change it in the registry of
the PDC, and it is most definately a "push" operation for a strictly NT
Luke Leighton, sure enough, knew more:
"the way it works is that the PDC sends out "delta"
notifications on UDP 138 braoadcasts, and the BDCs notice them
(hopefully), and do a "pull"of hte SAM using a
NetrSamLogon MSRPC call. we have a client-side
netr_sam_logon implementaion in
rpcclient, we don't
have the UDP 138 notifications."
Greg then pointed out that NT BDC's update their databases when triggered by a "push" operation from the PDC, but Samba PDC's do not issue these, ergo an NT BDC with a Samba PDC probably would not work too well. Luke concurred.
9. How to Share Netscape Profiles, Cross-Platform
9 Feb 2000 (8 posts) Archive Link: "The sameNetscape Profile on every machine"
People: Todd Pfaff, Aaron Brooks, Andy Polyakov,
Cord-H. Fricke was interested in letting his users drag their
Netscape Navigator profiles around their NT network automatically. He
posted this question to
Aaron Brooks and Todd Pfaff both suggested an interesting tactic: tell Netscape on NT to look in your Unix home directory for its profile; assuming you arrange to have your home directory mounted on each NT box you log into, this will work. Todd went into some detail:
after installing netscape on an nt workstation, set these registry keys:
\Registry\Machine\SOFTWARE\Netscape\Netscape Navigator\Users = CurrentUser = Default Default DirRoot = h:\.netscape UserName = EmailAddr =
then add something like this to your nt workstation logon script:
rem copy netscape preferences file if it doesn't exist. if not exist H:\.netscape md H:\.netscape if not exist H:\.netscape\prefs.js xcopy /f /v s:\netscape\users\default\prefs.js H:\.netscape\
this will create a default
directory at user logon if it does not yet exist. you could also do
a little more work to, for example, merge global changes to the
netscape preferences into each user's
h: is mapped to the user's unix/nt shared home
directory on a samba server.
h:\.netscape is then
shared by netscape in both unix and nt environments. as far as i
know, this is working fine as of netscape 4.7 (at least no one has
complained to me about problems with their netscape preferences when
moving between the two platforms).
In addition, Aaron noted: "Another alternative, actually a set of alternatives, is to use Netscapes roaming profile configuration. This can be implemented either via LDAP or an Apache module. Due to how Netscape implements this, however, it seems to be less reliable. Plus, these methods make the system less maintainable since they are not part of the filesystem."
Next question: how a user can get a new profile automatically when first logging in. Todd's solution above seems to have addressed this already, but Andy Polyakov volunteered another solution:
If your setup is policy driven (NTconfig.POL on DC's netlogon share), then consider throwing following to CLASS USER section:
CATEGORY "Netscape" KEYNAME "Software\Netscape\Netscape Navigator\UserInfo" POLICY "Freeze Profile location" VALUENAME "ProfileDirectory" VALUEON "Z:\.nt\Netscape\profile" ACTIONLISTON KEYNAME "Software\Netscape\Netscape Navigator\UserInfo" VALUENAME "DirRoot" VALUE "Z:\.nt\Netscape\profile" END ACTIONLISTON PART "Bind Netscape profile to Z:\.nt" TEXT END PART END POLICY ; Freeze Profile location END CATEGORY ; Netscape
It's based upon http://help.netscape.com/kb/consumer/19990708-9.html.
10. Another Simultaneous-Multi-Domain Question
11 Feb 2000 (14 posts) Archive Link: "more domains on one server"
People: Martin Lorenz, Luke Leighton, , VMWare, Seth Vidal
Martin Lorenz put an urgent problem before
"my boss wants me to get a NT
domain-controller up and running by friday next week and i definitely
want to do this with samba under linux. the main problem is: he wants
to have three different domains managed by one server. how do i do
Luke Leighton had a good laugh.
wanted it to be done with NT? HA! lovely :) that tickles me, that
He and Seth Vidal both suggested running three separate
smbd processes on three separate IP numbers. Not an
uncommon configuation, at least with Samba. (Not possible with NT, as
far as anyone knows. Unless perhaps one could run multiple instances
of NT under VMWare. Essentially one would be using VMWare much like
its namesake, VM, IBM's recursive OS for mainframes.)
Then Robert Magier reported that starting multiple
processes didn't work: only one would start. After some traffic
between him and Seth, trying to debug the situation, it came to light
that all the
smbds wanted to use the same PID file.
Separate PID files solved the problem.
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.