PAM-NTDOM: Compile Errors

Paul J Collins pjdc at
Mon Jul 10 18:33:24 GMT 2000

>>>>> "Luke" == Luke Kenneth Casson Leighton <lkcl at> writes:

    >> I never meant to imply that it was.  Let me give a 
    >> bit of history here.  Luke and I (and others) have over 
    >> the months and years had discussions over issues 
    >> similar to this.  Luke has in the past wanted to make 
    >> UNIX into NT in every aspect.  Not necessarily from a
    >> services point of view, but from an architectural 
    >> point of view.  

    Luke> both.  the possibility of being able to tell microsoft,
    Luke> here, install these services on this version of linux, with
    Luke> these libraries, then hit "compile" on your office msdn
    Luke> development environment, and you will get a native linux
    Luke> office suite.
First of all, Microsoft Office running on a bunch of Windows-emulating
services (would CSRSS.EXE be one of these?) is not "native".  In a
similar fashion, a Unix app running on cygwin and using X for its
display is not really "native" either.  I follow the Wine project a
little, and the things they have to do in order to run Windows
binaries lift Wine a large step above being a toolkit.

Second, I don't understand why this is a useful goal.  Programs such
as Emacs have had difficulty mixing well with NT (e.g. NT's primitive
process model; okay "different" process model); why should the
converse not be true?  And if you follow that approach to NT/Unix
integration, why not just drop Samba, implement the Win32 API (Wine!)
the NT system traps and suggest that Microsoft recompile SRV.EXE, et
al. on Unix?

Which brings me to my next point.  Office and such rely on a number of
chunks of software, updated versions of which these applications
frequently install themselves.  One example that springs to mind is
the COM/OLE libaries.  Do you reimplement those, or use Microsoft's

    >> I disagree.  Not that I think one is better than the 
    >> other.  I simply think Samba is an interoperability tool,
    >> and not an operating system.

    Luke> samba requires support from the OS it is running on.  we can
    Luke> provide a mapping between NT and unix worlds as best we can
    Luke> [and will have to continue to do so].

One example of Samba meeting the underlying OS with some unease is in
the area of utmp/wtmp handling.  As I recall, almost every Unix is/was
a special case.

    Luke> direct support from the underlying OS to provide that
    Luke> interoperability - e.g a filesystem that provides Unicode
    Luke> direct-to-disk - would be of enormous benefit.

I'm pretty sure that ext2fs on Linux can store UTF-8 filenames; is
UTF-8 just "not good enough" (both in this case and in general)?  Can
other Unix filesystems handle UTF-8 in a useful fashion?
    Luke> *shrug*.  pam_ntdom is not a high priority for me.  plus,

Maybe not, but it has a user base, and it is a priority for them.

    Luke> the way that PAM works makes it difficult to securely
    Luke> provide the exact semantics of nt authentication.

I'd like some details on this; if it's been written up, an URL.  I've
found it difficult to locate documentation for PAM in the past.

    Luke> so, for those people who have been asking, i tell them that
    Luke> pam_ntdom is superceded by winbindd.

I hope this doesn't sound sarcastic, but is it safe to assume that
winbindd is close to a "final solution", or is there a chance of it
being abandoned in the same fashion as pam_ntdom has been?

This is a bit of a ramble.  Hope some sense shines through.


Paul Collins <pjdc at> - - - - - - - [ A&P,a&f ]
 GPG: 0A49 49A9 2932 0EE5 89B2  9EE0 3B65 7154 8131 1BCD
 PGP: 88BA 2393 8E3C CECF E43A  44B4 0766 DD71 04E5 962C
"Where?  Where is the town?  Now it's nothing but flowers!"

More information about the samba-ntdom mailing list