VFS programming / PANIC when opening new files

[Esh, Andrew]

I've spent some time thinking about this. The code near line 1153 in
smbd/open.c is as correct as it can be. If it's calling a "HAVE_NO_ACLS" vfs
layer directly, it will avoid the SIGSEGV. If it's calling it through a VFS
shim, there can't be an assumption that the shim won't handle the fact that
there is no ACL support in the default VFS functions. This means putting
#ifdef HAVE_NO_ACLS into the code near line 1153 in smbd/open.c is the wrong
thing to do.

I also thought it might be helpful to have the skel_init function in
examples/VFS/skel.c do the same sort of initialization of its own ops list
as it is done in smbd/vfs.c, with the #ifdef HAVE_NO_ACLS determining if the
function pointers for skel_chmod_acl and skel_fchmod_acl are null. This
would simply push the problem further up the stack, and could break other
code which does not test those function pointers for null.

The only place I can see where a change obviously needs to be made is in
skel_chmod_acl and skel_fchmod_acl. They need to avoid the SIGSEGV, and
return something. I thought about returning True, but I can't be certain
what the assumptions are in the calling code if these calls appear to be
successful when they are not. I think the best thing to do is return -1,
which appears to be tested for in a number of places, and set errno to
ENOSYS, which also appears to be an expected response. ENOSYS means
"function not implemented", which actually is the case.

Someone who is more familiar with the code should review this and decide if
it's the right thing to do. I realize this is a nitpicky, rare case error,
but the combination of not having ACLs and trying to use the skel code has
occurred, and will always cause a segment violation, so it might as well be
fixed.

Here's the delta:

Index: skel.c
===================================================================
RCS file: /cvsroot/samba/examples/VFS/skel.c,v
retrieving revision 1.7.2.3
diff -u -c -r1.7.2.3 skel.c
cvs server: conflicting specifications of output style
*** skel.c	28 Apr 2003 17:48:45 -0000	1.7.2.3
--- skel.c	30 Apr 2003 12:23:47 -0000
***************
*** 232,242 ****
--- 232,252 ----
  
  static BOOL skel_chmod_acl(struct connection_struct *conn, const char
*name, mode_t mode)
  {
+ 	// These can be NULL if HAVE_NO_ACLS is set, so prevent SIGSEGV
+ 	if (!default_vfs_ops.chmod_acl) {
+ 		errno = ENOSYS;
+ 		return -1;
+ 	}
  	return default_vfs_ops.chmod_acl(conn, name, mode);
  }
  
  static BOOL skel_fchmod_acl(struct files_struct *fsp, int fd, mode_t mode)
  {
+ 	// These can be NULL if HAVE_NO_ACLS is set, so prevent SIGSEGV
+ 	if (!default_vfs_ops.fchmod_acl) {
+ 		errno = ENOSYS;
+ 		return -1;
+ 	}
  	return default_vfs_ops.fchmod_acl(fsp, fd, mode);
  }
  

-----Original Message-----
From: Joachim [mailto:JOFT at gmx.de]
Sent: Tuesday, April 29, 2003 1:29 PM
To: samba-technical at lists.samba.org
Subject: Re: VFS programming / PANIC when opening new files


Hi!

> Can you send me a gdb backtrace?

Sure. The backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x40244069 in skel_fchmod_acl () from 
/usr/local/src/samba-SAMBA_3_0/examples/VFS/skel.so
#2  0x080b7dbe in open_file_shared1 (conn=0x831d4d8, fname=0xbffff2c0 
"home/tester2/asd.sdf", psbuf=0xbffff240, desired_access=3, share_mode=127,
    ofun=18, mode=422, oplock_request=0, Access=0x0, action=0x0) at 
smbd/open.c:1153
#3  0x080b7151 in open_file_shared (conn=0x831d4d8, fname=0xbffff2c0 
"home/tester2/asd.sdf", psbuf=0xbffff240, share_mode=127, ofun=18, 
mode=422,
    oplock_request=0, Access=0x0, action=0x0) at smbd/open.c:784
#4  0x0809b43a in reply_mknew (conn=0x831d4d8, inbuf=0x401ff008 "", 
outbuf=0x40220008 "", dum_size=68, dum_buffsize=65535) at smbd/reply.c:1071
#5  0x080c7730 in switch_message (type=3, inbuf=0x401ff008 "", 
outbuf=0x40220008 "", size=68, bufsize=65535) at smbd/process.c:758
#6  0x080c77e7 in construct_reply (inbuf=0x401ff008 "", outbuf=0x40220008 
"", size=68, bufsize=65535) at smbd/process.c:788
#7  0x080c7b4f in process_smb (inbuf=0x401ff008 "", outbuf=0x40220008 "") at

smbd/process.c:889
#8  0x080c8828 in smbd_process () at smbd/process.c:1308
#9  0x08214e8a in main (argc=4, argv=0xbffff954) at smbd/server.c:877
#10 0x40093bb4 in __libc_start_main () from /lib/libc.so.6


So the error/bug seems to be somewhere in the default function for 
fchmod_acl, because this is the only function called by skel_fchmod_acl ... 
???

I remember, that when I used my own VFS module (with logging), there was a 
call to open, ftruncate, lock and sometimes there was a last call to fchmod 
(!!) before the corresponding smbd died ...
So this last (logged) call seems to be followed by a call to 
skel_fchmod_acl. But there I never put any logging lines.


Now I replaced the line

return default_vfs_ops.fchmod_acl(fsp, fd, mode);

in the function skel_fchmod_acl (in skel.c) with

return 1;

RESULT: It works :-)! No SegFaults!

BTW: I assume 1 = TRUE and 0 = FALSE, because of the return type of 
skel_fchmod_acl (BOOL). Are there any constants for true/false? "TRUE" (and 
"FALSE") doesn't work (compile time: "ERROR_XX_DONT_USE_TRUE").
 
>> A saw that the VFS API changed a bit (init_module, ...). What's about a
>> corresponding function for the old vfs_done in alpha23 ?
> There will be some kind of a smb_register_exit_event() function to
> register your clean up function.

"There will be"?? => So there is heavy activity on VFS issues/code at the 
moment?

 Joachim