The Samba-Bugzilla – Bug 2827
make_connection calls SMB_VFS_STAT before SMB_VFS_CONNECT
Last modified: 2005-08-24 10:21:10 UTC
In smbd/service.c function make_connection, line 614:
Someone changed a 'stat' call into SMB_VFS_STAT. The stat behaved correctly, the
SMB_VFS_STAT will cause problems because the call happens before
SMB_VFS_CONNECT. So opaque layers that depend on the SMB_VFS_CONNECT to
initialize some data structures will not and the SMB_VFS_STAT call will have
these internal structures uninitialized.
In my example, I had a database filesystem and before SMB_VFS_CONNECT there is
no connection to the database so SMB_VFS_STAT failed horrible death. It took me
quite some time to debug this problem.
It still worked in 3.0.6
The semantics changed, sorry it blew up your code.
We can never to direct filesystem "stat" calls any more on a connection as
that completely bypasses the VFS. For example in your case the VFS was connected
to a database backend, with no filesystem underneath it at all.
The vfs_init() on the connection struct should set up the vfs module pointers so
a stat call can be done. We have a chicken and egg problem with the "connect"
VFS hook. The problem is we haven't yet set up the connect struct other than the
vfs pointers, as we need to do a VFS_STAT to ensure that the underlying path
associated with the connection really exists as part of setting up the
connection struct. What the latest code does is to assume that after the
vfs_init call is done that it's safe to do vfs calls as root, and then once the
connection struct is set up then the "connect" vfs hook is called to set up the
I agree this is difficult in your case, but there's also the problem of
supporting the preexec scripts, which must be done before the "connect" vfs hook
as they may create the underlying directory.
Maybe the correct semantic is to call the "connect" hook after the
"change_to_user" call lets Samba know it should be doing things as that user. Do
you concur ?
Created attachment 1290 [details]
How about this as a fix going forward ?
Looking at the patch, I think that should do the trick. Thank you.
Fixed in SVN.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.