Re: alternate form of tconX response
Well some clients (e.g. the cifs vfs) would not be hurt by the wct=7 because the fields are at the end of the wct area and would be ignored, but I would not rely on that in general. The server really should check the tconx flags to determine which to send. The mechanism is simple - if in the tconX request the client sets the tcon flags to 0x0008 it indicates its desire for getting the mask (as Win2K and XP do) - so give it the extra 2 DWORDs in the response - otherwise don't. Same thing on the NTCreateX presumably - one of the multiple flag fields that the client sends on the NTCreateX request will end up being what tells the server it wants the extra fields in the response. Steve French Senior Software Engineer Linux Technology Center - IBM Austin phone: 512-838-2294 email: [EMAIL PROTECTED] Shirish Kalele <[EMAIL PROTECTED]> on 08/15/2002 08:06:48 PM To:[EMAIL PROTECTED] cc:Steven French/Austin/IBM@IBMUS, <[EMAIL PROTECTED]> Subject: Re: alternate form of tconX response Thanks, Jeremy. The one thing I haven't looked at is whether older clients can handle these new-fangled tconX and ntcreate&X replies, or whether we'll have to fall back to the old ones based on remote_arch. I'll try and patch HEAD soon with a proper fix both for share and file ACLs. - Shirish On Thu, 15 Aug 2002 [EMAIL PROTECTED] wrote: >On Thu, Aug 15, 2002 at 04:15:20PM -0700, Shirish Kalele wrote: >> 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. > >Damn good work ! We should definately put this into HEAD. > >Thanks Shirish ! > >Jeremy. >
Re: alternate form of tconX response
Thanks, Jeremy. The one thing I haven't looked at is whether older clients can handle these new-fangled tconX and ntcreate&X replies, or whether we'll have to fall back to the old ones based on remote_arch. I'll try and patch HEAD soon with a proper fix both for share and file ACLs. - Shirish On Thu, 15 Aug 2002 [EMAIL PROTECTED] wrote: >On Thu, Aug 15, 2002 at 04:15:20PM -0700, Shirish Kalele wrote: >> 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. > >Damn good work ! We should definately put this into HEAD. > >Thanks Shirish ! > >Jeremy. >
Re: alternate form of tconX response
On Thu, Aug 15, 2002 at 04:15:20PM -0700, Shirish Kalele wrote: > 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. Damn good work ! We should definately put this into HEAD. Thanks Shirish ! Jeremy.
Re: alternate form of tconX response
Yes, it does. If you just set the number of works to 42 without setting up access masks, offline caching will stop working because you're essentially giving no permissions for anyone to access the file offline. I didn't apply this patch to Samba_2_2 because it creates access masks using the standard Unix permissions. It needs to be extended to handle POSIX ACLs. - Shirish On Thu, 15 Aug 2002 [EMAIL PROTECTED] wrote: >On Thu, Aug 15, 2002 at 04:15:20PM -0700, Shirish Kalele wrote: >> 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. > >Ok, so with this patch does the offline sync still work correctly ? > >Jeremy. >
Re: alternate form of tconX response
On Thu, Aug 15, 2002 at 04:15:20PM -0700, Shirish Kalele wrote: > 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. Ok, so with this patch does the offline sync still work correctly ? Jeremy.
Re: alternate form of tconX response
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 b
alternate form of tconX response
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: [EMAIL PROTECTED]
