Discussion:
Re: dfs path construction fixup for / character in \\server\share component of dfs path
(too old to reply)
Igor Mammedov
2008-04-23 19:55:44 UTC
Permalink
Attached is dfs path construction fixup for / character in
\\server\share component of dfs path. Let me know if you see any
problem - but it gets Samba past the problem with not returning
STATUS_PATH_NOT_COVERED
similar change will have to be made to build_full_dfs_path_from_dentry
in cifs_dfs_ref.c
This makes it easier for me to test the remainder of the changes
needed to the SMB GetDFSReferral function(s). Has anyone checked on
the answer to Al's question on submount expiry from a few days ago?
I've just tested it and the patch fixed a problem with the lack of
STATUS_PATH_NOT_COVERED with unix-ext enabled on samba server.
1. samba with unix-ext enabled returns (5th packet) dfs link as a symbolic link,
but for dfs code it should be the directory type so we could fix it in the time
of creating inode and get the server generated inode number.

No. Time Source Destination Protocol Info
1 0.000000 192.168.133.129 192.168.133.1 SMB Trans2 Request, QUERY_PATH_INFO, Query File Unix Basic, Path: //192.168.133.1/dfs/dfs2
2 0.000385 192.168.133.1 192.168.133.129 SMB Trans2 Response, QUERY_PATH_INFO, Error: STATUS_PATH_NOT_COVERED
3 0.000670 192.168.133.129 192.168.133.1 TCP 46662 > microsoft-ds [ACK] Seq=127 Ack=40 Win=1728 Len=0 TSV=509648098 TSER=3625842022

4 0.006911 192.168.133.129 192.168.133.1 SMB Trans2 Request, QUERY_PATH_INFO, Query File Unix Basic, Path: /dfs2
5 0.007110 192.168.133.1 192.168.133.129 SMB Trans2 Response, QUERY_PATH_INFO

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - here our chance to get it working

6 0.016002 192.168.133.129 192.168.133.1 SMB Trans2 Request, QUERY_PATH_INFO, Query File Unix Link, Path: /dfs2
7 0.016219 192.168.133.1 192.168.133.129 SMB Trans2 Response, QUERY_PATH_INFO
8 0.049621 192.168.133.129 192.168.133.1 SMB Trans2 Request, QUERY_PATH_INFO, Query File Unix Basic, Path: //192.168.133.1/dfs/msdfs:\172.16.61.1\dfs2
9 0.050706 192.168.133.1 192.168.133.129 SMB Trans2 Response, QUERY_PATH_INFO, Error: STATUS_OBJECT_NAME_NOT_FOUND

Patches that make dfs working in this case are attached.



2. samba with unix-ext disabled returns STATUS_OBJECT_NAME_NOT_FOUND on the second
query (5th packet). Replacing '\' with '/' doesn't help. It looks we will not be
able to make this case work unless we disable server generated inode numbers and fill
up junction point inode with fake values. Another way to make it working is to fix
samba code so that it would return inode info (with directory type) on the second call
as win2k does.

No. Time Source Destination Protocol Info
1 0.000000 192.168.133.129 192.168.133.1 SMB Trans2 Request, QUERY_PATH_INFO, Query File All Info, Path: \\192.168.133.1\dfs\dfs2
2 0.000576 192.168.133.1 192.168.133.129 SMB Trans2 Response, QUERY_PATH_INFO, Error: STATUS_PATH_NOT_COVERED
3 0.000746 192.168.133.129 192.168.133.1 TCP 37925 > microsoft-ds [ACK] Seq=127 Ack=40 Win=1728 Len=0 TSV=510792731 TSER=3626976733

4 0.004212 192.168.133.129 192.168.133.1 SMB Trans2 Request, QUERY_PATH_INFO, Query File All Info, Path: \dfs2
5 0.004606 192.168.133.1 192.168.133.129 SMB Trans2 Response, QUERY_PATH_INFO, Error: STATUS_OBJECT_NAME_NOT_FOUND
--
Best regards,

-------------------------
Igor Mammedov,
niallain "at" gmail.com




-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Adds-to-dns_resolver-checking-if-the-server-name-is.patch
Type: text/x-patch
Size: 2721 bytes
Desc: not available
Url : http://lists.samba.org/archive/linux-cifs-client/attachments/20080423/cef542e9/0001-Adds-to-dns_resolver-checking-if-the-server-name-is.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-fixed-compatibility-issue-with-samba-a-refferal-req.patch
Type: text/x-patch
Size: 2244 bytes
Desc: not available
Url : http://lists.samba.org/archive/linux-cifs-client/attachments/20080423/cef542e9/0002-fixed-compatibility-issue-with-samba-a-refferal-req.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Workaround-for-working-with-samba-unix-extentions-m.patch
Type: text/x-patch
Size: 1406 bytes
Desc: not available
Url : http://lists.samba.org/archive/linux-cifs-client/attachments/20080423/cef542e9/0003-Workaround-for-working-with-samba-unix-extentions-m.bin
Jeremy Allison
2008-04-24 00:12:04 UTC
Permalink
Post by Igor Mammedov
Attached is dfs path construction fixup for / character in
\\server\share component of dfs path. Let me know if you see any
problem - but it gets Samba past the problem with not returning
STATUS_PATH_NOT_COVERED
similar change will have to be made to build_full_dfs_path_from_dentry
in cifs_dfs_ref.c
This makes it easier for me to test the remainder of the changes
needed to the SMB GetDFSReferral function(s). Has anyone checked on
the answer to Al's question on submount expiry from a few days ago?
I've just tested it and the patch fixed a problem with the lack of
STATUS_PATH_NOT_COVERED with unix-ext enabled on samba server.
1. samba with unix-ext enabled returns (5th packet) dfs link as a symbolic link,
but for dfs code it should be the directory type so we could fix it in the time
of creating inode and get the server generated inode number.
No. Time Source Destination Protocol Info
1 0.000000 192.168.133.129 192.168.133.1 SMB Trans2 Request, QUERY_PATH_INFO, Query File Unix Basic, Path: //192.168.133.1/dfs/dfs2
2 0.000385 192.168.133.1 192.168.133.129 SMB Trans2 Response, QUERY_PATH_INFO, Error: STATUS_PATH_NOT_COVERED
3 0.000670 192.168.133.129 192.168.133.1 TCP 46662 > microsoft-ds [ACK] Seq=127 Ack=40 Win=1728 Len=0 TSV=509648098 TSER=3625842022
4 0.006911 192.168.133.129 192.168.133.1 SMB Trans2 Request, QUERY_PATH_INFO, Query File Unix Basic, Path: /dfs2
5 0.007110 192.168.133.1 192.168.133.129 SMB Trans2 Response, QUERY_PATH_INFO
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - here our chance to get it working
6 0.016002 192.168.133.129 192.168.133.1 SMB Trans2 Request, QUERY_PATH_INFO, Query File Unix Link, Path: /dfs2
7 0.016219 192.168.133.1 192.168.133.129 SMB Trans2 Response, QUERY_PATH_INFO
8 0.049621 192.168.133.129 192.168.133.1 SMB Trans2 Request, QUERY_PATH_INFO, Query File Unix Basic, Path: //192.168.133.1/dfs/msdfs:\172.16.61.1\dfs2
9 0.050706 192.168.133.1 192.168.133.129 SMB Trans2 Response, QUERY_PATH_INFO, Error: STATUS_OBJECT_NAME_NOT_FOUND
Patches that make dfs working in this case are attached.
Thanks. I'm going to fix Samba 3.2 (not sure if this will make
final release) to return directory not symlink on QPATHINFO
if the requested path is a DFS path and it's a DFS link.

Can you test the patch once it's complete please ?

Jeremy.
Jeremy Allison
2008-04-24 00:19:29 UTC
Permalink
Post by Jeremy Allison
Post by Igor Mammedov
Attached is dfs path construction fixup for / character in
\\server\share component of dfs path. Let me know if you see any
problem - but it gets Samba past the problem with not returning
STATUS_PATH_NOT_COVERED
similar change will have to be made to build_full_dfs_path_from_dentry
in cifs_dfs_ref.c
This makes it easier for me to test the remainder of the changes
needed to the SMB GetDFSReferral function(s). Has anyone checked on
the answer to Al's question on submount expiry from a few days ago?
I've just tested it and the patch fixed a problem with the lack of
STATUS_PATH_NOT_COVERED with unix-ext enabled on samba server.
1. samba with unix-ext enabled returns (5th packet) dfs link as a symbolic link,
but for dfs code it should be the directory type so we could fix it in the time
of creating inode and get the server generated inode number.
No. Time Source Destination Protocol Info
1 0.000000 192.168.133.129 192.168.133.1 SMB Trans2 Request, QUERY_PATH_INFO, Query File Unix Basic, Path: //192.168.133.1/dfs/dfs2
2 0.000385 192.168.133.1 192.168.133.129 SMB Trans2 Response, QUERY_PATH_INFO, Error: STATUS_PATH_NOT_COVERED
3 0.000670 192.168.133.129 192.168.133.1 TCP 46662 > microsoft-ds [ACK] Seq=127 Ack=40 Win=1728 Len=0 TSV=509648098 TSER=3625842022
4 0.006911 192.168.133.129 192.168.133.1 SMB Trans2 Request, QUERY_PATH_INFO, Query File Unix Basic, Path: /dfs2
5 0.007110 192.168.133.1 192.168.133.129 SMB Trans2 Response, QUERY_PATH_INFO
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - here our chance to get it working
6 0.016002 192.168.133.129 192.168.133.1 SMB Trans2 Request, QUERY_PATH_INFO, Query File Unix Link, Path: /dfs2
7 0.016219 192.168.133.1 192.168.133.129 SMB Trans2 Response, QUERY_PATH_INFO
8 0.049621 192.168.133.129 192.168.133.1 SMB Trans2 Request, QUERY_PATH_INFO, Query File Unix Basic, Path: //192.168.133.1/dfs/msdfs:\172.16.61.1\dfs2
9 0.050706 192.168.133.1 192.168.133.129 SMB Trans2 Response, QUERY_PATH_INFO, Error: STATUS_OBJECT_NAME_NOT_FOUND
Patches that make dfs working in this case are attached.
Thanks. I'm going to fix Samba 3.2 (not sure if this will make
final release) to return directory not symlink on QPATHINFO
Hmmmmm. Looking carefully that's the wrong thing to do.

I think the client is doing the wrong thing here when it
gets the STATUS_PATH_NOT_COVERED error. Shouldn't it then
call TRANS2_GET_DFS_REFERRAL instead of doing a QPATHINFO ?

Jeremy.
Igor Mammedov
2008-04-24 13:04:45 UTC
Permalink
Post by Jeremy Allison
Post by Jeremy Allison
Post by Igor Mammedov
Attached is dfs path construction fixup for / character in
\\server\share component of dfs path. Let me know if you see any
problem - but it gets Samba past the problem with not returning
STATUS_PATH_NOT_COVERED
similar change will have to be made to build_full_dfs_path_from_dentry
in cifs_dfs_ref.c
This makes it easier for me to test the remainder of the changes
needed to the SMB GetDFSReferral function(s). Has anyone checked on
the answer to Al's question on submount expiry from a few days ago?
I've just tested it and the patch fixed a problem with the lack of
STATUS_PATH_NOT_COVERED with unix-ext enabled on samba server.
1. samba with unix-ext enabled returns (5th packet) dfs link as a symbolic link,
but for dfs code it should be the directory type so we could fix it in the time
of creating inode and get the server generated inode number.
No. Time Source Destination Protocol Info
1 0.000000 192.168.133.129 192.168.133.1 SMB Trans2 Request, QUERY_PATH_INFO, Query File Unix Basic, Path: //192.168.133.1/dfs/dfs2
2 0.000385 192.168.133.1 192.168.133.129 SMB Trans2 Response, QUERY_PATH_INFO, Error: STATUS_PATH_NOT_COVERED
3 0.000670 192.168.133.129 192.168.133.1 TCP 46662 > microsoft-ds [ACK] Seq=127 Ack=40 Win=1728 Len=0 TSV=509648098 TSER=3625842022
4 0.006911 192.168.133.129 192.168.133.1 SMB Trans2 Request, QUERY_PATH_INFO, Query File Unix Basic, Path: /dfs2
5 0.007110 192.168.133.1 192.168.133.129 SMB Trans2 Response, QUERY_PATH_INFO
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - here our chance to get it working
6 0.016002 192.168.133.129 192.168.133.1 SMB Trans2 Request, QUERY_PATH_INFO, Query File Unix Link, Path: /dfs2
7 0.016219 192.168.133.1 192.168.133.129 SMB Trans2 Response, QUERY_PATH_INFO
8 0.049621 192.168.133.129 192.168.133.1 SMB Trans2 Request, QUERY_PATH_INFO, Query File Unix Basic, Path: //192.168.133.1/dfs/msdfs:\172.16.61.1\dfs2
9 0.050706 192.168.133.1 192.168.133.129 SMB Trans2 Response, QUERY_PATH_INFO, Error: STATUS_OBJECT_NAME_NOT_FOUND
Patches that make dfs working in this case are attached.
Thanks. I'm going to fix Samba 3.2 (not sure if this will make
final release) to return directory not symlink on QPATHINFO
Can try to do it, have 'v3-2-test' branch checked out already.
Post by Jeremy Allison
Hmmmmm. Looking carefully that's the wrong thing to do.
I think the client is doing the wrong thing here when it
gets the STATUS_PATH_NOT_COVERED error. Shouldn't it then
call TRANS2_GET_DFS_REFERRAL instead of doing a QPATHINFO ?
I'm doing the second call with a short path to get inode info
including server generated inode number. If not for the last
then second call could be omitted and inode be filled with fake
values and locally generated ino.

PS:
Windows server does not object against the second call and returns
info on the dfs junction point (as directory).
More uniform behavior between different implementations would be
better for all.
--
Best regards,

-------------------------
Igor Mammedov,
niallain "at" gmail.com
Jeremy Allison
2008-04-26 00:22:36 UTC
Permalink
Post by Igor Mammedov
I'm doing the second call with a short path to get inode info
including server generated inode number. If not for the last
then second call could be omitted and inode be filled with fake
values and locally generated ino.
Windows server does not object against the second call and returns
info on the dfs junction point (as directory).
More uniform behavior between different implementations would be
better for all.
Very important question here. Do you set the FLAGS2_DFS_PATHNAMES
bit in the flags2 when you do this QPATHINFO call on the short path ?

Jeremy.
Jeremy Allison
2008-04-26 00:50:37 UTC
Permalink
Post by Jeremy Allison
Post by Igor Mammedov
I'm doing the second call with a short path to get inode info
including server generated inode number. If not for the last
then second call could be omitted and inode be filled with fake
values and locally generated ino.
Windows server does not object against the second call and returns
info on the dfs junction point (as directory).
More uniform behavior between different implementations would be
better for all.
Very important question here. Do you set the FLAGS2_DFS_PATHNAMES
bit in the flags2 when you do this QPATHINFO call on the short path ?
Actually, all these questions would be answered if you'd just
forward me the binary wireshark trace you have here.

Thanks !

Jeremy.
Jeremy Allison
2008-04-26 02:17:20 UTC
Permalink
Post by Igor Mammedov
I'm doing the second call with a short path to get inode info
including server generated inode number. If not for the last
then second call could be omitted and inode be filled with fake
values and locally generated ino.
Windows server does not object against the second call and returns
info on the dfs junction point (as directory).
More uniform behavior between different implementations would be
better for all.
Can you try this patch against the 3.2 code please. It should
cause smbd to return a directory on the short QFILEINFO call.

Jeremy.
-------------- next part --------------
diff --git a/source/smbd/trans2.c b/source/smbd/trans2.c
index 709eb39..74b167b 100644
--- a/source/smbd/trans2.c
+++ b/source/smbd/trans2.c
@@ -3768,6 +3768,28 @@ static void call_trans2qpipeinfo(connection_struct *conn,
}

/****************************************************************************
+ Needed to show the msdfs symlinks as directories. Modified psbuf
+ to be a directory.
+****************************************************************************/
+
+static bool check_msdfs_link(connection_struct *conn,
+ const char *pathname,
+ SMB_STRUCT_STAT *psbuf)
+{
+ if(lp_host_msdfs() &&
+ lp_msdfs_root(SNUM(conn)) &&
+ is_msdfs_link(conn, pathname, psbuf)) {
+
+ DEBUG(5,("check_msdfs_link: Masquerading msdfs link %s "
+ "as a directory\n",
+ pathname));
+ psbuf->st_mode = (psbuf->st_mode & 0xFFF) | S_IFDIR;
+ return true;
+ }
+ return false;
+}
+
+/****************************************************************************
Reply to a TRANS2_QFILEPATHINFO or TRANSACT2_QFILEINFO (query file info by
file name or file id).
****************************************************************************/
@@ -3806,6 +3828,7 @@ static void call_trans2qfilepathinfo(connection_struct *conn,
struct ea_list *ea_list = NULL;
uint32 access_mask = 0x12019F; /* Default - GENERIC_EXECUTE mapping from Windows */
char *lock_data = NULL;
+ bool ms_dfs_link = false;
TALLOC_CTX *ctx = talloc_tos();

if (!params) {
@@ -3959,10 +3982,20 @@ static void call_trans2qfilepathinfo(connection_struct *conn,
reply_unixerror(req, ERRDOS, ERRbadpath);
return;
}
+
+ ms_dfs_link = check_msdfs_link(conn,fname,&sbuf);
+
} else if (!VALID_STAT(sbuf) && SMB_VFS_STAT(conn,fname,&sbuf) && (info_level != SMB_INFO_IS_NAME_VALID)) {
- DEBUG(3,("call_trans2qfilepathinfo: SMB_VFS_STAT of %s failed (%s)\n",fname,strerror(errno)));
- reply_unixerror(req, ERRDOS, ERRbadpath);
- return;
+ int saved_errno = errno;
+
+ ms_dfs_link = check_msdfs_link(conn,fname,&sbuf);
+
+ if (!ms_dfs_link) {
+ errno = saved_errno;
+ DEBUG(3,("call_trans2qfilepathinfo: SMB_VFS_STAT of %s failed (%s)\n",fname,strerror(errno)));
+ reply_unixerror(req, ERRDOS, ERRbadpath);
+ return;
+ }
}

fileid = vfs_file_id_from_sbuf(conn, &sbuf);
@@ -3987,7 +4020,11 @@ static void call_trans2qfilepathinfo(connection_struct *conn,
else
base_name = p+1;

- mode = dos_mode(conn,fname,&sbuf);
+ if (ms_dfs_link) {
+ mode = dos_mode_msdfs(conn,fname,&sbuf);
+ } else {
+ mode = dos_mode(conn,fname,&sbuf);
+ }
if (!mode)
mode = FILE_ATTRIBUTE_NORMAL;
Igor Mammedov
2008-04-27 18:00:47 UTC
Permalink
Post by Jeremy Allison
Post by Igor Mammedov
I'm doing the second call with a short path to get inode info
including server generated inode number. If not for the last
then second call could be omitted and inode be filled with fake
values and locally generated ino.
Windows server does not object against the second call and returns
info on the dfs junction point (as directory).
More uniform behavior between different implementations would be
better for all.
Can you try this patch against the 3.2 code please. It should
cause smbd to return a directory on the short QFILEINFO call.
Thanks for a patch, I've just tested it. Packets dumps are attached.

Short summary:
1. unix extentions are disabled. Works.
* ls on the directory that has a dfs link "dfs2" shows that it is directory
* second QPATHINFO on "\dfs2" returns that it is directory (pkts 28-29)

2. unix extentions are enabled. Works partially.
* ls on the directory that has a dfs link "dfs2" shows that it is a link
(pkts 26-27). Would be nice if it was listed as directory here.
* second QPATHINFO on "\dfs2" returns that it is directory (pkts 36-37)

Traverse over DFS junction point now works in both both cases.
--
Best regards,

-------------------------
Igor Mammedov,
niallain "at" gmail.com




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smb32.Jeremy_unix_ext_disabled.pcap
Type: application/octet-stream
Size: 9561 bytes
Desc: not available
Url : http://lists.samba.org/archive/linux-cifs-client/attachments/20080427/f2f164e8/smb32.Jeremy_unix_ext_disabled-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smb32.Jeremy_unix_ext_enabled.pcap
Type: application/octet-stream
Size: 14286 bytes
Desc: not available
Url : http://lists.samba.org/archive/linux-cifs-client/attachments/20080427/f2f164e8/smb32.Jeremy_unix_ext_enabled-0001.obj
Jeremy Allison
2008-04-28 23:06:09 UTC
Permalink
Post by Igor Mammedov
Post by Jeremy Allison
Post by Igor Mammedov
I'm doing the second call with a short path to get inode info
including server generated inode number. If not for the last
then second call could be omitted and inode be filled with fake
values and locally generated ino.
Windows server does not object against the second call and returns
info on the dfs junction point (as directory).
More uniform behavior between different implementations would be
better for all.
Can you try this patch against the 3.2 code please. It should
cause smbd to return a directory on the short QFILEINFO call.
Thanks for a patch, I've just tested it. Packets dumps are attached.
1. unix extentions are disabled. Works.
* ls on the directory that has a dfs link "dfs2" shows that it is directory
* second QPATHINFO on "\dfs2" returns that it is directory (pkts 28-29)
2. unix extentions are enabled. Works partially.
* ls on the directory that has a dfs link "dfs2" shows that it is a link
(pkts 26-27). Would be nice if it was listed as directory here.
* second QPATHINFO on "\dfs2" returns that it is directory (pkts 36-37)
Traverse over DFS junction point now works in both both cases.
Can you send me the same packet trace against Windows please ? I need
to see exactly how Windows responds to the \dfs2 query with flags2
set.

Jeremy.
Jeremy Allison
2008-04-28 23:52:04 UTC
Permalink
Post by Igor Mammedov
Post by Jeremy Allison
Post by Igor Mammedov
I'm doing the second call with a short path to get inode info
including server generated inode number. If not for the last
then second call could be omitted and inode be filled with fake
values and locally generated ino.
Windows server does not object against the second call and returns
info on the dfs junction point (as directory).
More uniform behavior between different implementations would be
better for all.
Can you try this patch against the 3.2 code please. It should
cause smbd to return a directory on the short QFILEINFO call.
Thanks for a patch, I've just tested it. Packets dumps are attached.
1. unix extentions are disabled. Works.
* ls on the directory that has a dfs link "dfs2" shows that it is directory
* second QPATHINFO on "\dfs2" returns that it is directory (pkts 28-29)
2. unix extentions are enabled. Works partially.
* ls on the directory that has a dfs link "dfs2" shows that it is a link
(pkts 26-27). Would be nice if it was listed as directory here.
* second QPATHINFO on "\dfs2" returns that it is directory (pkts 36-37)
Traverse over DFS junction point now works in both both cases.
Ok, I just had a long chat with Volker about this and he made
some good points.

With unix extensions enabled doing a QPATHINFO or FINDFIRST
with a UNIX info level on /server/share/dfs/path always
returns PATH_NOT_COVERED, as it should.

Doing a QPATHINFO or FINDFIRST on /dfs/path with a UNIX info
level currently returns symlink, which exposes the Samba
implementation of the junction. For a Windows info level
it returns BAD_PATH, which is a bug in the Samba server
and part of my patch trivially fixes this.

The question I'm pondoring is - is it correct to spoof
this to show a directory when you are querying with a
UNIX info level ? On the positive side it hides the
Samba implementations. On the negative side it makes
it impossible to write code that actually allows the
client to see what is really on disk.

This goes against the spirit of the UNIX extensions,
which is to show straight "posix" on the wire. Now
we are in somewhat unknown territory, in that we're
defining the interface between UNIX extensions and
MSDFS, but if I spoof to show a directory when it's
really a symlink I'm lying to clients.

If I do the spoof there's no way for clients that
want to see the symlink (maybe in order to change
it) to do so.

I could add some "magic foo" and show the symlink
if the QPATHINFO request flags2 doesn't contain the
DFS_PATH bit, and show as a directory if it does,
but this sucks (and I hate magic foo such as this).

I'm inclined as Volker suggested to leave the current
behavior with UNIX extensions alone, as the client
knows it's dealing with a DFS path (after all the
first call got PATH_NOT_COVERED) and it allows the
client to code around the discrepancy (as you say
traverse over DFS junctions now works with the client)
but still allows the UNIX extensions to show what
is really on disk in full POSIX glory :-).

Steve, others, please comment !

Cheers,

Jeremy.
Guenter Kukkukk
2008-04-30 00:16:18 UTC
Permalink
Hi Steve,

please have a look at the following:
in inode.c line 392 replace
bool adjustTZ = bool;
with
bool adjustTZ = false;

in cifsacl.c line 592 replace
bool oplock = false;
with
int oplock = 0;

Cheers, G?nter
Igor Mammedov
2008-05-21 18:58:25 UTC
Permalink
Post by Jeremy Allison
Ok, I just had a long chat with Volker about this and he made
some good points.
With unix extensions enabled doing a QPATHINFO or FINDFIRST
with a UNIX info level on /server/share/dfs/path always
returns PATH_NOT_COVERED, as it should.
Doing a QPATHINFO or FINDFIRST on /dfs/path with a UNIX info
level currently returns symlink, which exposes the Samba
implementation of the junction. For a Windows info level
it returns BAD_PATH, which is a bug in the Samba server
and part of my patch trivially fixes this.
The question I'm pondoring is - is it correct to spoof
this to show a directory when you are querying with a
UNIX info level ? On the positive side it hides the
Samba implementations. On the negative side it makes
it impossible to write code that actually allows the
client to see what is really on disk.
This goes against the spirit of the UNIX extensions,
which is to show straight "posix" on the wire. Now
we are in somewhat unknown territory, in that we're
defining the interface between UNIX extensions and
MSDFS, but if I spoof to show a directory when it's
really a symlink I'm lying to clients.
As I understand 'extensions', should not break interface
they are extending. Symlink for DFS junction point is
just the way chosen by samba for storing dfs metadata.
So showing it as directory isn't breaking 'posix' way
at all, just hides particular implementation details.

Also for compatibility with clients it would be better
to behave like MS even with "Unix Ext." turned on.
Working the same way in both modes for similar concepts
reduces headache for everyone.
Post by Jeremy Allison
If I do the spoof there's no way for clients that
want to see the symlink (maybe in order to change
it) to do so.
Typically client expects to see directory here.
MS uses another way for getting metadata for such dirs.
When I dig up how they do it, I'll try to write corresponding
code for cifs to show which referrals up/down/connected
for a dfs junction point.
Post by Jeremy Allison
I could add some "magic foo" and show the symlink
if the QPATHINFO request flags2 doesn't contain the
DFS_PATH bit, and show as a directory if it does,
but this sucks (and I hate magic foo such as this).
I'm inclined as Volker suggested to leave the current
behavior with UNIX extensions alone, as the client
knows it's dealing with a DFS path (after all the
first call got PATH_NOT_COVERED) and it allows the
client to code around the discrepancy (as you say
traverse over DFS junctions now works with the client)
but still allows the UNIX extensions to show what
is really on disk in full POSIX glory :-).
Steve, others, please comment !
Cheers,
Jeremy.
Magic is really sucks. Because of DFS junction point
is symlink in samba, when unix ext. is on, we had to do
that magic thing in the kernel code.
Now we have following behavior:
1. when client makes 'ls' for the first time on the
directory with DFS links, 'ls' shows them as symlinks.
2. when we follow through a such 'symlink', it finely
becomes a directory.
That magic!!!
Of cause it is possible to rewrite such 'symlink' in readdir
syscall handler, but is it the best way?

IMHO:
For a client the way better to see a directory from the start.
(common code for handling this case for MS and Samba servers)
and no magic at all.
--
Best regards,

-------------------------
Igor Mammedov,
niallain "at" gmail.com
Jeremy Allison
2008-05-24 05:46:27 UTC
Permalink
Post by Igor Mammedov
Magic is really sucks. Because of DFS junction point
is symlink in samba, when unix ext. is on, we had to do
that magic thing in the kernel code.
1. when client makes 'ls' for the first time on the
directory with DFS links, 'ls' shows them as symlinks.
2. when we follow through a such 'symlink', it finely
becomes a directory.
That magic!!!
Of cause it is possible to rewrite such 'symlink' in readdir
syscall handler, but is it the best way?
For a client the way better to see a directory from the start.
(common code for handling this case for MS and Samba servers)
and no magic at all.
I can easily do this in the server, the problem is
how we define what is "correct" from the client
view with the UNIX extensions turned on.

Because we are overloading the filesystem to
store DFS links as symlinks, it's arguable
which way they should be seen. If a symlink
with the corrcet contents is "magically" seen
as a directory, then a client can write a
symlink which is then no longer seen as a
symlink, but turns into a directory when
queried.

The problem is the Samba implementation
is bleeding out onto the wire here. As we're
stuck with it for the time being we have to
make the best of it. Trouble is, I'm not
sure what exactly the right decision is
here..

Jeremy.
Steve French
2008-05-24 06:33:51 UTC
Permalink
Post by Jeremy Allison
Post by Igor Mammedov
Magic is really sucks. Because of DFS junction point
is symlink in samba, when unix ext. is on, we had to do
that magic thing in the kernel code.
1. when client makes 'ls' for the first time on the
directory with DFS links, 'ls' shows them as symlinks.
2. when we follow through a such 'symlink', it finely
becomes a directory.
That magic!!!
For a client the way better to see a directory from the start.
(common code for handling this case for MS and Samba servers)
and no magic at all.
I can easily do this in the server, the problem is
how we define what is "correct" from the client
view with the UNIX extensions turned on.
The problem is the Samba implementation
is bleeding out onto the wire here. As we're
stuck with it for the time being we have to
make the best of it. Trouble is, I'm not
sure what exactly the right decision is
here..
I don't know what is best either ... but whatever we do we should be
careful not to hurt performance ... I would like to know what happens
on: readdir of a directory contains a DFS "symlink" (followed by
lookup of the symink inode which is cached) followed by get sym link
info. Does that return STATUS_PATH_NOT_COVERED and everything works
...?
--
Thanks,

Steve
Loading...