alternate form of tconX response

Shirish Kalele kalele at veritas.com
Thu Aug 15 14:16:01 GMT 2002


Steve,

There are two extra DWORDs of similar form in the NTCreate&X replies sent
by Windows 2000. Win2K sends 42 words instead of the known 34.

While exploring client-side caching, I discovered that these are actually
access masks for the "User" who's opening the file and "Everyone Else"
respectively.  These access masks are used instead of the original NTACL
when the file is accessed offline through the CSC cache. The two access
masks you are seeing are probably similar "Simple File Sharing"
equivalents of share ACLs.

Here's a small patch (against Samba 2.2.4) to illustrate SFS masks. You
can see the effect different masks have on the files cached by CSC.

Index: smbd/nttrans.c
===================================================================
RCS file: /data/cvs/samba/source/smbd/nttrans.c,v
retrieving revision 1.104.4.47
diff -u -r1.104.4.47 nttrans.c
--- smbd/nttrans.c	2002/04/17 21:53:35	1.104.4.47
+++ smbd/nttrans.c	2002/04/22 17:56:31
@@ -611,6 +611,55 @@
 	return chain_reply(inbuf,outbuf,length,bufsize);
 }

+int create_secmasks(files_struct *fsp, SMB_STRUCT_STAT sbuf,
+		    SEC_ACCESS *vsecmask, SEC_ACCESS *gsecmask)
+{
+	user_struct *vuser;
+	BOOL owner = False, owning_group = False, guest = False;
+	mode_t vmode, gmode;
+	int i = 0;
+
+	vuser = get_valid_user_struct(fsp->vuid);
+	if (!vuser)
+		return -1;
+
+	if (vuser->uid == sbuf.st_uid) {
+		owner = True;
+		vmode = (sbuf.st_mode & S_IRWXU) >> 6;
+		gmode = ((sbuf.st_mode & S_IRWXG) >> 3) &
+			(sbuf.st_mode & S_IRWXO);
+	} else {
+		for (i = 0; i < vuser->n_groups; i++) {
+			if (vuser->groups[i] == sbuf.st_gid) {
+				owning_group = True;
+				vmode = (sbuf.st_mode & S_IRWXG) >> 3;
+				gmode = ((sbuf.st_mode & S_IRWXU) >> 6) &
+					(sbuf.st_mode & S_IRWXO);
+				break;
+			}
+		}
+
+		if (!owning_group) {
+			guest = True;
+			vmode = (sbuf.st_mode & S_IRWXO);
+			gmode = ((sbuf.st_mode & S_IRWXU) >> 6) &
+				((sbuf.st_mode & S_IRWXG) >> 3);
+		}
+	}
+
+	/* Map vmode */
+        vsecmask->mask |= ((vmode & S_IROTH) ? UNIX_ACCESS_R : 0 );
+        vsecmask->mask |= ((vmode & S_IWOTH) ? UNIX_ACCESS_W : 0 );
+        vsecmask->mask |= ((vmode & S_IXOTH) ? UNIX_ACCESS_X : 0 );
+
+	/* Map gmode */
+        gsecmask->mask |= ((gmode & S_IROTH) ? UNIX_ACCESS_R : 0 );
+        gsecmask->mask |= ((gmode & S_IWOTH) ? UNIX_ACCESS_W : 0 );
+        gsecmask->mask |= ((gmode & S_IXOTH) ? UNIX_ACCESS_X : 0 );
+
+	return 0;
+}
+
 /****************************************************************************
  Reply to an NT create and X call.
 ****************************************************************************/
@@ -644,6 +693,9 @@
 	files_struct *fsp=NULL;
 	char *p = NULL;
 	time_t c_time;
+
+	SEC_ACCESS vsecmask, gsecmask;
+
 	START_PROFILE(SMBntcreateX);

 	/* If it's an IPC, use the pipe handler. */
@@ -884,6 +936,8 @@
 		return ERROR_DOS(ERRDOS,ERRnoaccess);
 	}

+	create_secmasks(fsp, sbuf, &vsecmask, &gsecmask);
+
 	/*
 	 * If the caller set the extended oplock request bit
 	 * and we granted one (by whatever means) - set the
@@ -896,9 +950,10 @@
 	if(oplock_request && EXCLUSIVE_OPLOCK_TYPE(fsp->oplock_type))
 		smb_action |= EXTENDED_OPLOCK_GRANTED;

-#if 0
+#define SFS_MASK 1
+#if SFS_MASK
 	/* W2K sends back 42 words here ! If we do the same it breaks offline sync. Go figure... ? JRA. */
-	set_message(outbuf,42,0,True);
+	set_message(outbuf,42,16,True);
 #else
 	set_message(outbuf,34,0,True);
 #endif
@@ -954,6 +1009,14 @@
 	p += 12;
 	SCVAL(p,0,fsp->is_directory ? 1 : 0);

+#if SFS_MASK
+        p = smb_buf(outbuf);
+        p += 6;
+        SIVAL(p, 0, vsecmask.mask); /* Full control for User ? */
+        p += 4;
+        SIVAL(p, 0, gsecmask.mask); /* Read control for Everyone? */
+#endif
+
 	DEBUG(5,("reply_ntcreate_and_X: fnum = %d, open name = %s\n", fsp->fnum, fsp->fsp_name));

 	result = chain_reply(inbuf,outbuf,length,bufsize);





On Thu, 15 Aug 2002, Steven French wrote:

>In the course of our recent poking around ntlmssp we discovered (or
>rediscovered perhaps) that the tconX response from Windows 2k (or XP) to
>Windows 2k has a wct of 7 not 3 as Samba and everyone else understands.
>Turns out that this is controlled by whether the client sets the tcon flags
>in the request to 0x0008 (the only flag bit that is documented is 0x0001
>which means "disconnect tid").   I confirmed this by forcing the Linux cifs
>vfs to set this tconX flag bit.   The two extra DWORDs that are being
>returned by Windows on the tconX response relate to access control (similar
>looking to access flags) - a common default is 0x001f01ff (twice).
>Changing the permissions on the root of the share causes these bits to
>change in interesting ways but we haven't quite put the puzzle together.
>Any ideas as to exactly why two access control dwords? and how to prove
>that they represent the access_flags we think that they do?  (the windows
>gui makes it tricky to set the bits granular enough to figure out how they
>map to these flag bits - it oversimplifies)
>
>Steve French
>Senior Software Engineer
>Linux Technology Center - IBM Austin
>phone: 512-838-2294
>email: sfrench at us.ibm.com
>




More information about the samba-technical mailing list