libsmbclient - Thread Saftey

Derrell Lipman derrell.lipman at unwireduniverse.com
Fri Oct 3 23:43:39 GMT 2008


On Fri, Oct 3, 2008 at 5:40 PM, David Collier-Brown <davec-b at rogers.com>wrote:

>  I did a check for MT-safe versus merely async-signal-safe functions in
> the samba4 libsmbclient, and found a number that need attention:


Hi David, thanks for reporting these!

I'm not sure which libsmbclient you're basing this on.  There is no
libsmbclient in samba4 unless it's something ancient from the early days of
samba4, and I can't find any calls to getpass -- one of the issues you raise
-- anyplace in samba3 (master) libsmb_*.c.  I did find one call to it in
clidfs.c but I'm not sure if/when that's called by libsmbclient code.

Please let me know what source tree you were looking at in locating these.
I'm going to create a bug report to keep track of these things so that I can
fix them when I have some time.

Thanks again,

Derrell


>
> 1) The MT-safe (or unsafe!) ones were:
>
> atof - convert string to double-precision number
>    MT-Level: MT-Safe as  long  as setlocale(3C) is not
>    called to change the locale.
>
> Found in:
> "./libsmbclient.c",
>      4697:          4730:
> ctime - convert date and time to string
>    MT-Level: MT-Safe , but note that the    return values  for  asctime(),
>  ctime(),  gmtime(),  and
>    localtime()  point  to thread-specific data whose content is
>    overwritten by each call by the same thread.
>
> Found in:
> "./libsmbclient.c",
>      4044:          4050:
> getpass - read a string of characters without echo
>    MT-Level: MT-Unsafe
>        This one needs a buffer and a semaphore to protect it,
>        and make it, in effect, a getpass_r
> Found in:
> "./clidfs.c",
>      203:
> inet_ntoa - Internet address manipulation
>    MT-Level: MT-Unsafe, static buffer is overwritten on
>    each call. Linux and Solaris *may* make this per-thread
>    of the compiler is told to generate MT code...
>
> Found in:
> "./namequery.c",
>      716:          723:          1083:     "./nmblib.c",
>      112:          802:          824:          839:
> readdir - read directory
>    The  readdir() function is unsafe in
>    multithreaded applications.  The  readdir_r() function is safe, and
>    should be used instead.
> Found in:
> "./libsmb_compat.c",
>      256:
>
> 2) The merely Async-Signal-Safe ones follow: as the change something
> external,
> two competing threads can fight over the results. If you really need to
> protect these, you need a semaphore that's visible to all callers of the
> library.  In general, that's too much work for too little value (;-))
>
> chmod - change access permission mode of file
> close - close a file descriptor
> creat - create a new file or rewrite an existing one
> fstat - get file status
> geteuid - get real user, effective user, real group, and effective group
> IDs
> getuid - get real user, effective user, real group, and effective group IDs
> kill - send a signal to a process or a group of processes
> lseek - move read/write file pointer
> mkdir - make a directory
> open - open a file
> read - read from file
> rename - change the name of a file
> rmdir - remove a directory
> stat - get file status
> time - get time
> unlink - remove directory entry
> write - write on a file
>
> --dave
>
>
>
>
>
> Jeremy Allison wrote:
>
>> On Fri, Oct 03, 2008 at 10:46:14AM -0400, Derrell Lipman wrote:
>>
>>  On Fri, Oct 3, 2008 at 10:14 AM, Pane, Chris <cpane at vanteon.com> wrote:
>>>
>>>
>>>  I have been using libsmbclient to do some smb share browsing in an
>>>> application. I have read that it is currently not thread safe in
>>>> samba-3.x.
>>>> Anyone know if there are plans for it to be made thread-safe in samba4?
>>>>
>>>
>>>
>>> Hi Chris,
>>>
>>> I believe I've eliminated all non-thread-safe issues from within
>>> libsmbclient itself (although that will require a thorough inspection to
>>> confirm), but the core functions within samba that libsmbclient calls
>>> have
>>> not been thread-safe.  Samba4 interfaces are, I think, inherently
>>> thread-safe.  Therefore, although no work has begun yet on creating a
>>> samba4
>>> version of libsmbclient (and it's not yet scheduled), I don't believe
>>> there's any reason why a samba4 libsmbclient can't or won't be
>>> thread-safe.
>>>
>>
>>
>> The easiest thing to do at the moment is wrap the libsmbclient
>> functions in a mutex. I'm looking at making the underlying
>> functions thread safe, but that's a longer term job.
>>
>> Jeremy.
>>
>>
> --
> David Collier-Brown,         | Always do right. This will gratify
> System Programmer and Author | some people and astonish the rest
> davecb at spamcop.net           |                      -- Mark Twain
> (416) 223-5943
>


More information about the samba-technical mailing list