smbwrapper/smbsh for Linux 2.4 -- I've got it closer to working

Derrell.Lipman at UnwiredUniverse.com Derrell.Lipman at UnwiredUniverse.com
Thu Dec 5 20:07:00 GMT 2002


I tracked down a number of articles from the archives discussing the various
problems with smbsh for Linux.  I am now getting much further than any of the
previous posters, but I could use some help.

Firstly, the problems with smbwrapper as shipped in Debian's package (2.2.3a)
are:

1. Although includes.h provides a hack for 64-bit locking, that file may not
   be included by wrapped.c and it needs the same kludge.  Patch attached,
   below.

2. real_readdir64() does not exist in the implementation.  readdir64() is a C
   library function, not a system call, so it must be loaded dynamically and
   called by a new real_readdir64() function.  Patch attached, below.

My current problems are:

1. If ~/.bash_history exists, the bash shell created by smbsh crashes.  I
   haven't been able to track down why.  For right now, I'm just ensuring that
   .bash_history is removed prior to running smbsh.  I'll get back to that
   later.

2. More importantly, it seems that sub-processes of the shell exec()'ed by
   smbsh are using only *some* of the wrapper function, not all of them.
   Using "strace -f", I can see the sub-process loading smbwrapper.so, and by
   adding calls to real_write() in wrapper.c, I can see when the wrapper
   functions are being called and when they're not.  The write() wrapper
   function gets called properly, but lstat64() does not.  For example, if I
   issue the command "ls /smb/" I am not seeing the wrapper function for
   lstat64 called.  Instead, the glibc function lstat64() is called, which of
   course tells me that /smb/ is not found.  At the same time, though, I'm
   seeing the wrapper function for the error message telling me that /smb/
   does not exist being called.  I should be seeing the wrapper function
   called in both cases (and if the wrapper for lstat64() were called, it
   should see the workgroups on the network).

Thoughts?  Ideas?

Thanks!

Derrell


------------------------------------------------------------------------------

*** wrapped.c~	Sat Feb  2 19:46:57 2002
--- wrapped.c	Thu Dec  5 14:44:33 2002
***************
*** 34,39 ****
--- 34,51 ----
  # define NULL ((void *)0)
  #endif
  
+ #if 1 /* djl */
+ /* this is a gross hack. 64 bit locking is completely screwed up on
+    i386 Linux in glibc 2.1.95 (which ships with RedHat 7.0). This hack
+    "fixes" the problem with the current 2.4.0test kernels 
+ */
+ #define fcntl fcntl64
+ #undef F_SETLKW 
+ #undef F_SETLK 
+ #define F_SETLK 13
+ #define F_SETLKW 14
+ #endif /* djl */
+ 
   int open(char *name, int flags, mode_t mode)
  {
  	if (smbw_path(name)) {

------------------------------------------------------------------------------


*** realcalls.c~	Wed Oct  7 06:58:12 1998
--- realcalls.c	Thu Dec  5 14:51:07 2002
***************
*** 47,49 ****
--- 47,89 ----
  	return real_utime(name, &buf);
  }
  #endif
+ 
+ #if 1 /* djl */
+ #include <dlfcn.h>
+ 
+ /*
+  * Additional function required for Linux / glibc.
+  *
+  * IMPORTANT NOTE: This function is *not* thread safe, due to the use of
+  * static variables.  The static variables avoid needing to dlopen() and
+  * dlsym() on each call, but should be protected from multiple threads by some
+  * form of mutex.
+  */
+  void *real_readdir64(void * pDir)
+ {
+     static void *   pLib = NULL;
+     static void *   (* pReadDir)(void *);
+     char *          pError;
+     
+     if (pLib == NULL)
+     {
+         if ((pLib = dlopen("/lib/libc.so.6", RTLD_LAZY)) == NULL)
+         {
+             printf("Could not dlopen /lib/libc.so.6\n");
+             return NULL;
+         }
+ 
+         pReadDir = dlsym(pLib, "readdir64");
+ 
+         if ((pError = dlerror()) != NULL)
+         {
+             dlclose(pLib);
+             printf("Could not get pointer to readdir64: %s\n", pError);
+             return NULL;
+         }
+     }
+ 
+     return (* pReadDir)(pDir);
+ }
+ 
+ #endif /* djl */



More information about the samba-technical mailing list