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