Re: Xinetd /tmp race?

[shalunov () MCCME RU (stanislav shalunov)]

Marc Heuse <marc () SUSE DE> writes:

> It's hard to secure a create-or-append open call, anyone with an
> idea for a standard solution?

You have missed a word in this sentence: ``It's _not_ hard...''

Translating this pseudocode to documented C is left as an exercise to
the reader.  Notice that you cannot unlink instead of move_file (why?)

The chunk of code you inserted would read:

ok = false
while not ok
        lstat the file
        if file doesn't exist
                open the file O_WRONLY|O_CREAT|O_EXCL
                if open failed
                        complain loudly
                        call move_file
                else
                        ok = true
                fi
        else
                open the file O_WRONLY|O_APPEND
                fstat the fd
                if inode number is not the same
                        complain very loundly
                        close file
                else
                        ok = true;
                fi
        fi
elihw

The procedure move_file:

ok = false
while not ok
        mktemp
        rename the file to the generated file name
        if rename failed
                complain loudly
        else
                ok = true
        fi
elihw

> [This patch leave xinetd vulnerable if /tmp is not sticky, so it's
> not 100% without changing the design or location of how the dump
> should be done.

The solution above does not rely on /tmp being sticky.

> But a system without a sticky /tmp is a problem anyway]

Following this logic you can come to nonsense.

--
Stanislav Shalunov      System Administrator, MCCME (http://www.mccme.ru/)
Hiroshima 45--Chernobyl' 86--Windows 95   |   Spam?  http://www.cauce.org/