Bug 129 - vfs.c readlink_check - SymLinks compare not right!
Summary: vfs.c readlink_check - SymLinks compare not right!
Status: RESOLVED WONTFIX
Alias: None
Product: Samba 2.2
Classification: Unclassified
Component: File Services (show other bugs)
Version: 2.2.8a
Hardware: All All
: P2 major
Target Milestone: ---
Assignee: Gerald (Jerry) Carter (dead mail address)
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-05-26 13:21 UTC by Thomas Wild
Modified: 2004-02-17 08:45 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Wild 2003-05-26 13:21:45 UTC
Might be I am wrong, but it seems that the behavior of wide link option 
has been changed since 2.2.7. So we have some problems on our large side 
to upgrade to 2.2.8a. Here is what I found, but it may be not the 
intention of samba developer!

There ist a new function called readlink_checkin smbd/vfs.c. In this 
function is a pattern compare to guarantee that a symbolic link is not 
ouside a share.So far - so good.

But in my opinion it would be better to check if the physical location 
and not the logical path of the link to the destination. In case that 
you have some necessary compatibilty links on the system, samba is not 
able to follow that link. And I think (hopefully right) that it is also 
safe to check the physical way - unstead the link path.

I've got I a alternative to solve this behavior, if the intention is not 
the right one - please ignore this request, if so fill free to use this 
patch.

And also a bzero call resets the buffer to zero which can be undefined 
after the readlink call, in spacial circumstances the strncmp and also 
the DEBUG/TRACE might be result in a NULL Pointer or segmentation failure??

regards

- Thomas Wild

--- vfs.c,o     Wed Feb  5 17:25:48 2003
+++ vfs.c       Mon May 19 16:10:14 2003
@@ -740,6 +740,7 @@
                 realdir[reallen] = 0;
         }

+        bzero( flink, sizeof(flink) );
         if (conn->vfs_ops.readlink(conn, name, flink, sizeof(pstring) 
-1) != -1) {
                 DEBUG(3,("reduce_name: file path name %s is a 
symlink\nChecking it's path\n", name));
                 if (*flink == '/') {
@@ -750,6 +751,24 @@
                         pstrcat(cleanlink, flink);
                 }
                 unix_clean_name(cleanlink);
+
+               if (!vfs_GetWd(conn,savedir)) {
+                       DEBUG(0,("couldn't vfs_GetWd for %s 
%s\n",name,cleanlink));
+                       return(False);
+               }
+
+               if (vfs_ChDir(conn,cleanlink) != 0) {
+                       DEBUG(0,("couldn't vfs_ChDir to %s\n",cleanlink));
+                       return(False);
+               }
+
+               if (!vfs_GetWd(conn,cleanlink)) {
+                       DEBUG(0,("couldn't vfs_GetWd for %s\n",cleanlink));
+                       vfs_ChDir(conn,savedir);
+                       return(False);
+               }
+
+               DEBUG(0,("real share path : [%s], real destination pfad 
[%s]\n",realdir,cleanlink));

                 if (strncmp(cleanlink, realdir, reallen) != 0) { 
                  			DEBUG(2,("Bad access attempt? s=%s dir=%s 		 		 
newname=%s l=%d\n", name, realdir, cleanlink,(int)reallen));

-- 
Thomas Wild

Telephones do not have constitutional rights to be accepted!
   - It's better to send me an Email ...
Comment 1 Thomas Wild 2003-06-11 05:03:24 UTC
I found out the problem is larger than I thought. Also in this procedure is a
wrong behavior in combination of automounters. F.i. if I use a relative link
inside the a home share self it will be rejected if wide links option is off.

In all cases it whould be a solution if share and link will be checked whether
they are under the same physical location. The logical path of the symlink is
not a sure indicator of an outside wide link in my view?!

For our large side we switched the the wide link option on to work around the
problem for the moment.

Thanks and regards

- Thomas
Comment 2 Gerald (Jerry) Carter (dead mail address) 2004-02-17 08:45:48 UTC
Sorry, but the 2.2 is not under development any longer.
If you can reproduce this bug against the latest 3.0 release, 
please reopen this bug and change the version in the report.
Thanks.