[Bug 107] samba-3.0.1

Alexander E. Patrakov semzx at newmail.ru
Fri Jan 2 03:22:16 PST 2004

On Friday 02 January 2004 12:19, Greg Schafer wrote:
> On Fri, Jan 02, 2004 at 11:03:23AM +0500, Alexander E. Patrakov wrote:
> > Also don't forget to check that this bogus bug fix is reverted (it
> > slipped into 3.0.1):
> >
> > https://bugs.samba.org/show_bug.cgi?id=863
> >
> > Looks like my comments added to this bug were ignored. Probably I should
> > also mail Jerry and notify him. This is also a show stopper for users
> > that have MIT Kerberos installed.
> Alexander, you really do lose the plot at times. If you analyse the
> situation you'll realise the autoconfigury fix is NOT bogus. The fix is
> correct, but apparently has exposed latent bugs in the code. Get a clue.

I will look again (which source file and line?) and try to get your apparent 
clue. But I have another one, this is the contents of /var/log/samba/log.smbd 
with the "log level" parameter set to 10. It clearly indicates that smbd 
3.0.1 tried to create a memory keytab (when a Windows 2003 domain user 
attempted to connect) and failed to do so. My opinion is that smbd should not 
even attempt to do so at runtime, because of the autoconf check at compile 

Let's at least verify that our Kerberos installations behave identically WRT 
memory keytabs and ccaches. As far as I understand, MIT Kerberos supports 
memory ccaches but not memory keytabs.

Do you use MIT or Heimdal Kerberos? Which version? I use MIT krb5-1.3.1. To 
test your Kerberos, I attached a test program "test_kt.c" that expects an 
argument, the name of keytab to resolve. Compile it:

gcc test_kt.c -lkrb5 -o test_kt

(depending on your krb5 compilation options, you may need to add -lcom_err)
and run at least with the following arguments:

./test_kt FILE:/tmp/foo
./test_kt MEMORY:
./test_kt BADTYPE:

What do you see? My results: no error with FILE:/tmp/foo, "Unknown Key table 
type" with other arguments.

Valid "default" keytab types are listed (for MIT Kerberos 1.3.1) in 
krb5-1.3.1/src/lib/krb5/keytab/ktbase.c. Other types can be registered 
dynamically with the krb5_kt_register function which is declared in 
/usr/include/krb5.h and defined in krb5-1.3.1/src/lib/krb5/keytab/ktbase.c.

Also I attached a test program "test_cc.c" that performs the same check with a 
credentials cache. MIT Kerberos supports MEMORY: ccache, but this is not used 
by SAMBA - it uses keytabs, not ccaches.

gcc test_cc.c -lkrb5 -o test_cc

./test_cc FILE:/tmp/foo
./test_cc MEMORY:
./test_cc BADTYPE:

My results: no error with first two arguments, "Unknown credential cache type" 
with BADTYPE:. The relevant Kerberos source file is 

One more test. Extract SAMBA 3.0.1 source. Change the reference to MEMORY: 
keytab to BADTYPE: keytab in line 26034 of the source/configure file. Run 
that script. Does it still say that memory keytab (in fact the nonexistent 
and certainly unsupported "badtype" keytab) is supported? My answer is yes. 
That's definitely wrong. And the relevant piece of configure.in did not 
change in CVS since 3.0.1.

> I take offence at your backhanded snide remarks.

You could prevent this thread of offence by sending me mail just after I added 
the comments to SAMBA's Bugzilla. This Bugzilla told me that it mailed a copy 
of my comments to you. Have you received them by mail?

I will pull the CVS version of SAMBA since Billy said that his showstopper was 
fixed in the CVS HEAD. I will apologize if the CVS version of SAMBA passes
my test (make it a member of a Windows 2003 controlled domain, log into 
another domain member or into the domain controller, try to pull a file from 
this SAMBA server). But because of my last test (where I edited the configure 
script), that's very unlikely unless they messed with something else.

And for the "BLFS is understaffed" issue: this may or may not be true. From my 
viewpoint, the additional issue is that there are no instructions on testing 
new BLFS packages (for LFS, we run builtin tests). Even two million people 
will not be sufficient if they don't know what to test, duplicate effort, 
miss special cases, etc. Of course Billy does a good work with SAMBA, but he 
should express his testing procedures by words so that others can read them 
and understand what is tested and what is not.

What I want is to create a set of use cases for each package that allows to do 
so. We must perform these tests when deciding whether a new version is good. 
For SAMBA, one such case is presented in the book, and one is outlined above. 
I don't know where it is better to put such cases. Bugzilla is not a good 
place since we open a new bug for an updated version of the package, and all 
accumulated use cases remain with an old bug.

And even for LFS packages, there should be different procedures for testing 
whether a new version is good and whether a known good version compiled 
correctly. Builtin tests that are part of the LFS book serve the second 
purpose quite well. But we just say "use a new version and see" when 

> PS - Why moan here? Why not be a responsible netizen and file a proper bug
> report with upstream instead of posting usless comments into a closed bug
> report that nobody is going to see?

In other Bugzillas, the right action is to REOPEN an improperly fixed bug and 
append comments. I didn't know beforehand that I don't have enough rights to 
do that, and I thought (wrongly) that posting comments will suffice. Of 
course now I know a more proper action, thanks.

Alexander E. Patrakov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_cc.c
Type: text/x-csrc
Size: 436 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/blfs-book/attachments/20040102/62ef4313/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_kt.c
Type: text/x-csrc
Size: 436 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/blfs-book/attachments/20040102/62ef4313/attachment-0001.c>

More information about the blfs-book mailing list