-----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-----
