BUG? utmp returning incorrect 'i' in 2.2

Toomas Soome tsoome at ut.ee
Fri Feb 16 18:24:36 GMT 2001


On Fri, 16 Feb 2001, Andrew Bartlett wrote:

> I have been hacking samba to include better PAM support, including
> session support, and have been paying rather too much attention to some
> of the debug output.  However one of the things seems to be 'just wrong'
> and it appears to be in the original code.
>
> In samba 2.2 utmp 'devices' are derived from records in a tdb, with the
> lowest claimed record used as the device (in the form smb/i).  However
> on the closing of a connection the value returned from utmp_yield_tdb is
> never the same as the original 'i' (0 in most cases), usually
> 135888504.  Running with 'utmp consolidate'  (a very nice feature) masks


this is bug in smbd/connection.c:

diff -u -r1.20.4.5 connection.c
--- connection.c        2001/01/12 19:28:02     1.20.4.5
+++ connection.c        2001/02/16 18:17:53
@@ -340,7 +340,7 @@
        }

        /* Save our result */
-       slotnum = (int) dbuf.dptr;
+       slotnum = *((int*)dbuf.dptr);


the problem is that session number will be read to buffer, dbuf.dptr is
pointer to this buffer. as you can see, they convert this pointer to int
and use it. the fix is obvious.

I heve reported this here and to several samba related people, but it
seems to me, they do not care about such bugfixes.


> this behavior, but without it the bug shows up in 'last' as 'user still
> logged in' despite them dissapering from 'w'.  The record is
> successfully deleted from the tdb, and that connection is reused (ie
> i=0) for future connections, therefore ending the 'connection' in wtmp.
>
> Is this a live one?
>
> My machine is RedHat 7.0 + Rawhide, and uses the dreaded (and
> misunderstood) gcc 2.96-69 (the one from their errata).  I am using a
> current CVS snapshot of samba, with some of my own patches (which
> shouldn't affect this issue).
>
> Thanks,
> Andrew Bartlett
> --
> Andrew Bartlett
> abartlet at pcug.org.au
>

toomas
-- 
Never put off till tomorrow what you can avoid all together.





More information about the samba-technical mailing list