Menu
▾
▴
[Tcl-bugs] [ tcl-Bugs-1613456 ] file readable lies with samba shared folder or file
|
From: SourceForge.net <no...@so...> - 2012-02-02 17:40:55
|
Bugs item #1613456, was opened at 2006-12-11 11:48 Message generated for change (Comment added) made by dgp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1613456&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 37. File System Group: obsolete: 8.4.14 >Status: Pending >Resolution: Fixed Priority: 6 Private: No Submitted By: Francois VOGEL (fvogelnew1) Assigned to: Vince Darley (vincentdarley) Summary: file readable lies with samba shared folder or file Initial Comment: On a Windows machine accessing a Linux remote PC directory shared with Samba, in wish with Tcl/Tk 8.4.14 binary distribution from ActiveState (g:/ is the samba drive): % file exists g:/ 1 % file readable g:/ 0 % dir g: [shows the network drive content] This is also the result for all directories in the hierarchy. The directories exist, they are not readable (BUG ?!?), but one can change to the directories with "cd" and the "dir" command shows their content. Now on a file: % file exists g:/<hierarchy>/pll_noise.sci 1 % file readable g:/<hierarchy>/pll_noise.sci 0 % file owned g:/<hierarchy>/pll_noise.sci 1 % file size g:/<hierarchy>/pll_noise.sci 8338 This file, pll_noise.sci was created by an admin user. The OS is a german Win2000 SP4 (build 5.00.2195). The samba network drive is only accessed from Windows, the admin user has full rights to the complete network drive (the hierarchy has been created from Windows). There are only 7-bit ASCII-characters in the network path, no white space, etc. The total length of the Windows network path including computername and all slashes is 62 characters and is of the structure \\\computer\dir1\dir2\dir3\dir4\dir5\dir6\pll_noise.sci The drive is used by several other Windows programs without problems (MSOffice, OpenOffice, Acroread). The file access properties of pll_noise.sci show all "allow" checkboxes checked. The directories of the hierarchy have no checks in neither "allow" nor "disallow" checkboxes, the checkbox "inherit properties from parent directory" is also blank, but in the "advanced" properties the user is granted full access. The file pll_noise.sci can be read with OpenOffice2, Notepad, etc, through the Samba network. But the check on file readable fails and this sounds wrong to me. Other files on the network drive (regardless of their position in the hierarchy) also have file readable to return 0 (wrong!), but can be opened with other Windows programs. Moving the file to a shared WinXP folder on an NTFS partition on another PC lets file readable return 1 correctly. I guess that the samba share is the cause here for an incorrect result of file readable. Francois ---------------------------------------------------------------------- >Comment By: Don Porter (dgp) Date: 2012-02-02 09:40 Message: Patch from fix-win-native-access branch committed for 8.4.20, 8.5.12, and 8.6b3. Continued testing strongly encouraged. In particular, the #define UNICODE variant of the trunk is likely to have some lingering problems. ---------------------------------------------------------------------- Comment By: Francois VOGEL (fvogelnew1) Date: 2012-01-14 06:19 Message: Well, five years at my report, I had to build a specific configuration with two conputers specially to test this patch. The results are apparently good: file readable answers 1 on the samba shared directory and on the file located in this share as well. The tricky thing is that fossil updating to just before the patch does not allow me to reproduce the original issue. Reasons are probably numerous: not the same computers, different linux distro, samba and windows versions, samba configuration file lost since my initial report, can't remember the exact configuration... Sorry for not being very informative, but I hope you understand that I had worked around the issue in my application right when it happened, and despite I kept the stuff alive for some time I saw no reason to maintain all this for an undefined amount of time that turned out to be five years. Well, at least the patch does not seem to harm... I may try further to reproduce the original issue, but no promises here, sorry. BtW, where did the patch come from? Did it come with a well-defined test case along with a well-defined (samba) configuration that I could reproduce? ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-01-13 10:26 Message: The branch 'fix-win-native-access' includes a patch that may fix the bug reported here. http://core.tcl.tk/tcl/info/0aabf0529e I'm not equipped to test the effectiveness of the patch, or whether it introduces any new test failures or other problems. I'd be grateful if folks who can and who are intersted in this bug and related bugs could do so, and report back whether the patch is suitable for merging into the release branches. ---------------------------------------------------------------------- Comment By: Francois VOGEL (fvogelnew1) Date: 2008-04-30 12:35 Message: Logged In: YES user_id=1245417 Originator: YES Hi, Yes, still here with cvs HEAD version (info pa spits 8.6a0). Francois ---------------------------------------------------------------------- Comment By: Francois VOGEL (fvogelnew1) Date: 2008-04-24 14:40 Message: Logged In: YES user_id=1245417 Originator: YES I will try if this specific bug is still here in 8.5.2, please allow me for some days to rebuild the configuration I had when I reported this more than one year ago. In the meantime, see a similar report in comp.lang.tcl: http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/18ec9547f7700607?hl=en# Francois ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2008-04-15 09:24 Message: Logged In: YES user_id=80530 Originator: NO Is this bug present in Tcl 8.5.2 ? ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2007-06-10 14:23 Message: Logged In: YES user_id=72656 Originator: NO related to 1661378 for vmware shared folders? ---------------------------------------------------------------------- Comment By: Julian Noble (juliannoble) Date: 2007-04-29 09:30 Message: Logged In: YES user_id=598324 Originator: NO I can confirm that I have this problem with samba-3.0.24,1 on FreeBSD-6.x From a windows2000 machine 'file writable' may declare a perfectly writable path unwritable. %file writable //machine/share 0 file mkdir //machine/share/xxx %file exists //machine/share/xxx 1 ---------------------------------------------------------------------- Comment By: Francois VOGEL (fvogelnew1) Date: 2007-01-04 13:45 Message: Logged In: YES user_id=1245417 Originator: YES Hi, I tracked the problem to the following narrower issue. In some Linux directory shared with Samba, create any file myfile.txt. Then play with the access rigths and see the results: chmod 0600 myfile.txt Then file readable $thefile answers: 1 in wish run on the Linux machine 0 in wish run on the Windows machine And file writable $thefile answers: 1 in wish run on the Linux machine 0 in wish run on the Windows machine chmod 0606 myfile.txt Then file readable $thefile answers: 1 in wish run on the Linux machine 1 in wish run on the Windows machine And file writable $thefile answers: 1 in wish run on the Linux machine 1 in wish run on the Windows machine i.e. the file must be granted access rights for the "Others" users group, otherwise it is neither readable nor writable, even by the user who created it. The smb.conf has map to guest = never and I created a Linux user with the same name and password as the Windows user, so that there is no login dialog when the Windows machine connects to the Linux samba share. The Windows login and passwords are sent by Windows to Samba, and Samba has this user included in its smbpasswd file. To sum up: It seems that a file once readable and writable by some user on Linux is not readable nor writable later by this same user if this user connects through the samba share. When run through a Samba share, file readable/writable appears to check not only the user rights but also the "others" access rights, and this is odd. Francois ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1613456&group_id=10894 |