Wireshark · Smb2-protocol: Re: [Smb2-protocol] FIDs

["Stefan (metze) Metzmacher" <metze@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

ronnie sahlberg schrieb:
> Metze,
> 
> Re your findings about the "weird" scoping of FIDs.
> 
> 
> It appears from your findings that a FID is scoped not by a Tree but by Server.

I assume the FID's are also scopes by the user session and not by the tree,

BTW: I think I found what the uint16_t after the buffercode is in the tcon reply
     it's 0x0001 for file shares, 0x0002 for IPC shares, 0x0003 for print shares

and what I found out yet, is:

the share I opened the file was \\vista-220\torture, C:\torture
and I tested then with
\\vista-220\C$, C:\
\\vista-220\ADMIN$, C:\WINDOWS
\\vista-220\D$, D:\ the vista-CTP DVD
\\vista-220\PRINTER1,
\\vista-220\IPC$,

if you open a file handle on a file share, you can you this on any
tcon of the same user session.

this worked for any file and print share, I tried,

only an the IPC$ share I got an error NT_STATUS_INVALID_DEVICE_REQUEST

what I need to test is what happens when I open a pipe on IPC$
and access it from a file share.

Also note if you do a tdis() on the tree the file was opened on,
the file gets autoclosed and it's accessable via the other tcons any more.

> That once you aquire a FID you can issue comnmands to access that FID
> through ANY tree you have mounted form the server?
> 
> 
> This raises some itneresting questions about the FID (bear with me
> while i extrapolate from NFS filehandles below).
> 
> 
> 1, If you aquire a FID to a file to one client,
> can you use that FID to access the file also across the IPC$ tree?
> (does the FID have to be present on the same filesystem as the TID or not?)
> ((in nfs you can do this))

it doesn't depend on the file system, but the IPC$ checkes the device type.

> 
> 2, If you have two clients A and B   and both have mapped the same
> share,   If A aquires a FID (and keeps the file open),
> can B access the file be using the same FID that A got?
> I.e. Can B start doing I/O to the file   based solely on the knowledge
> about a specific FID but without actually opening the file?
> ((in nfs you can do this))

that don't work, note the above only worked with tcons,
of the same user session,

if you do this:

tcon with session1 on \\vista-220\torture
tcon with session2 on \\vista-220\torture

then open the file on the first tcon,
when you then try to use it on the 2nd tcon,
you get NT_STATUS_NOT_FOUND, which means the FID isn't found


> 
> 3, Does the authorization checks follow the FID or the session?

as this only works on tcon from the same session, that's not a problem.

> Another thing is the content of the FID,   it is definitely not a
> random blob like GUIDs are normally.
> Instead it appears to consist of 4 32 bit integers of which the last
> one is always (?) 0xffffffff.
> I.e. there is some structure imposed on the FID by the server.
> This is also something NFS servers always do.
> I would not be surprised if one would find that the first 12 bytes of
> the FID contain things such as
> 1,   Filesystem/Volume ID number
> 2,   Inode number
> 3,   A generation number/counter that increments by one for each Create.
> 
> If then the FID describes the filesystem/inode etc of the file   what
> then about the last 4 bytes?

I'm not shure about that...

- --
metze

Stefan Metzmacher <metze at samba.org> www.samba.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDl9tym70gjA5TCD8RAl5bAJ9j6PoilZi8vfpKW1mAXC4QHjfzkwCfWWtW
6hsWBP0FoVEkFjSxT2EcNu8=
=Vb1z
-----END PGP SIGNATURE-----