Bug 3088 - Excel can not open XLS on read-only samba share
Excel can not open XLS on read-only samba share
Status: RESOLVED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.20
Other FreeBSD
: P3 major
: none
Assigned To: Jeremy Allison
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-12 21:11 UTC by Alex Masterov
Modified: 2005-10-08 06:10 UTC (History)
1 user (show)

See Also:


Attachments
Sniff of try to open xls file from read-only samba share with MS Excel (2.86 KB, application/octet-stream)
2005-09-12 21:19 UTC, Alex Masterov
no flags Details
Sniff of try to open xls file from read-only XP share with MS Excel (11.21 KB, application/octet-stream)
2005-09-12 21:34 UTC, Alex Masterov
no flags Details
Sniff of executing echo xxx >file (868 bytes, application/octet-stream)
2005-10-03 01:43 UTC, Alex Masterov
no flags Details
Sniff of executing echo xxx >file over XP share (482 bytes, application/octet-stream)
2005-10-03 02:13 UTC, Alex Masterov
no flags Details
More complicated sniff (5.40 KB, application/octet-stream)
2005-10-03 19:51 UTC, Alex Masterov
no flags Details
Capture showing what happens on my system. (3.98 KB, application/octet-stream)
2005-10-03 20:44 UTC, Jeremy Allison
no flags Details
smbd level 10 log covering the same time as the sniff. (41.85 KB, text/plain)
2005-10-03 20:46 UTC, Jeremy Allison
no flags Details
Yet another sniff (3.65 KB, application/octet-stream)
2005-10-03 21:59 UTC, Alex Masterov
no flags Details
Level 10 log covering above sniff (38.51 KB, text/plain)
2005-10-03 22:01 UTC, Alex Masterov
no flags Details
Patch to give me more info (481 bytes, patch)
2005-10-04 13:51 UTC, Jeremy Allison
no flags Details
My samba config (1.12 KB, text/plain)
2005-10-04 19:20 UTC, Alex Masterov
no flags Details
FreeBSD specific patches used to build my samba. (1.46 KB, application/octet-stream)
2005-10-04 19:24 UTC, Alex Masterov
no flags Details
Lev 10 log file after patching open.c (11.58 KB, text/plain)
2005-10-04 20:19 UTC, Alex Masterov
no flags Details
Sniff echo xxx >file on XP share (R/W share R/O file) (2.35 KB, application/octet-stream)
2005-10-04 21:11 UTC, Alex Masterov
no flags Details
Proposed patch. (720 bytes, patch)
2005-10-05 15:36 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Masterov 2005-09-12 21:11:43 UTC
Samba 3.0.20
store dos attributes = yes (i.e. there is no readonly attribute on files)
User can not write on share
Excel - XP,2003
Client OS: Win'98 and WinXP

Excel produces a error message when user tries to open XLS file from samba resource.
Comment 1 Alex Masterov 2005-09-12 21:19:08 UTC
Created attachment 1440 [details]
Sniff of try to open xls file from read-only samba share with MS Excel

In my humble opinion this is interesting:
Packet #15 - client request to Open AndX file in Read-Write mode
Packet #16 - server resposes success error code and returns FID
Comment 2 Alex Masterov 2005-09-12 21:34:09 UTC
Created attachment 1441 [details]
Sniff of try to open xls file from read-only XP share with MS Excel

packet #22: request to open file in read-write mode
packet #23: Error: Access Denied
packet #25: request to open file in read-only mode
packet #31: success

Result: Excel normaly opened file in read-only mode
Comment 3 Jeremy Allison 2005-09-12 22:41:11 UTC
I'll take a look at this as soon as I'm in a place where I can get
at my vmware excell sessions. What version of Excel ?
Jeremy.
Comment 4 Alex Masterov 2005-09-13 02:11:06 UTC
Excel XP
I've just verified that Excel 2003 opens file on read-only samba share.
Comment 5 Jeremy Allison 2005-09-28 13:47:32 UTC
Ok these sniffs are very interesting. Apparently we're allowing an OPEN_AND_X
call with read/write request to succeed on a read-only share. I'm going to check
that this specific case is fixed in the current SAMBA_3_0_RELEASE code and if so
I'll close this one out.
Jeremy.
Comment 6 Jeremy Allison 2005-09-28 14:15:58 UTC
I've tested with smbclient with the current 3.0.20a code and this case is
definately denied. I think this bug is fixed with 3.0.20a - please re-open if
you can reproduce with 3.0.20a.
Thanks,
Jeremy.
Comment 7 Alex Masterov 2005-10-02 21:46:07 UTC
I've reproduced this problem with 3.0.20a
Comment 8 Alex Masterov 2005-10-03 01:43:54 UTC
Created attachment 1465 [details]
Sniff of executing echo xxx >file

There is a simple way to reproduce this bug without Excel at all.

1. map any read-only samba share as a network drive (e.g. V:)
2. find a file on network drive WITHOUT read-only attribute (e.g.
V:\1\test.txt)
3. run echo xxx >file (e.g. echo xxx >V:\1\test.txt)

Result:

C:\WINDOWS>echo xxx >V:\1\test.txt

The network has responded incorrectly.
Abort, Fail?

Sniff attached.
Samba 3.0.20a
Comment 9 Alex Masterov 2005-10-03 02:13:40 UTC
Created attachment 1466 [details]
Sniff of executing echo xxx >file over XP share

The same as previous, but drive was mapped from Windows XP.

C:\WINDOWS>echo xxx >V:\1\test.txt
File creation error

sniff attached
Comment 10 Jeremy Allison 2005-10-03 09:38:55 UTC
Boy I wish you'd sent these in *before* we shipped 3.0.20a.... That would have
enabled us to fix before ship.
Jeremy.
Comment 11 Jeremy Allison 2005-10-03 13:40:38 UTC
This is a different openX request to the previous one. This is a "create if not
exist, truncate if exists" call - the previous one (the one I fixed for 3.0.20a)
was a "open if exists, fail if not exists" call.
Jeremy.
Comment 12 Jeremy Allison 2005-10-03 16:31:50 UTC
I have tried with a Win98 client and a Samba 3.0.20a server and I can *NOT*
reproduce this error with the "echo XXX >\foo" trick.
Looking at my sniff I get "Access Denied" on the OpenX with create mode 0x12
(truncate file if not exists, create file if does not exist) and desired access
0x22 (deny write, open for read/write) - exactly the same OpenX call as your sniff.
Please check that 3.0.20a is running on your system, the latest sniff you posted
looks like a sniff from a 3.0.20 smbd server.
Jeremy.
Comment 13 Alex Masterov 2005-10-03 19:00:53 UTC
Excuse me, but how can I get 3.0.20a before it was shipped?
svn up gave me 3.0.21pre1
Comment 14 Alex Masterov 2005-10-03 19:12:24 UTC
Jeremy did you have "store dos attributes = yes" in smb.conf?

By default samba sets read-only attribute on every file on read-only share.
If file has read-only attribute error can not be reproduced.

But if "store dos attributes" is set to yes a file on read-only share but
without read-only attribute can exist. On these files error with "echo xxx
>file" can be reprodused, i.e. file must not have read-only attribute.
Comment 15 Alex Masterov 2005-10-03 19:51:17 UTC
Created attachment 1474 [details]
More complicated sniff

This can be demonstrated with this sniff.
Samba version is 3.0.20a (packet #4)
file V:\1\test-ro.txt has read-only attribute, V:\1\test.txt has not. (packet
#20 )
echo to file without read-only attribute finished with network error
echo to file with read-only attribute finished with access denied
Comment 16 Jeremy Allison 2005-10-03 20:44:59 UTC
Created attachment 1475 [details]
Capture showing what happens on my system.

Quite simply this DOES NOT HAPPEN when I try and do what you suggest with Win98
against a Samba 3.0.20a read-only share. Here is the capture trace of when I
attempt to do :

dir test.txt
echo xxx >\test.txt

I get "file creation error" (which is the mapping of access denied).

Looking at the code in 3.0.20a I cannot see any way that you are getting the
results you are getting, which makes me doubt you are running that release.

Jeremy.
Comment 17 Jeremy Allison 2005-10-03 20:46:40 UTC
Created attachment 1476 [details]
smbd level 10 log covering the same time as the sniff.

Debug level 10 log from smbd covering the same sniff. Note that the file is not
shown as read-only. This is working correctly for me.
Jeremy
Comment 18 Jeremy Allison 2005-10-03 20:59:39 UTC
I even downloaded the raw 3.0.20a source code and checked that smbd/open.c is
identical to smbd/open.c in the SAMBA_3_0_RELEASE SVN tree.
This is the relevent section of smbd/open.c that should make what you're
reporting impossible :

   1441         /*
   1442          * Ensure we can't write on a read-only share or file.
   1443          */
   1444
   1445         if (flags != O_RDONLY && file_existed &&
   1446             (!CAN_WRITE(conn) ||
IS_DOS_READONLY(existing_dos_attributes))) {
   1447                 DEBUG(5,("open_file_ntcreate: write access requested for "
   1448                          "file %s on read only %s\n",
   1449                          fname, !CAN_WRITE(conn) ? "share" : "file" ));
   1450                 set_saved_error_triple(ERRDOS, ERRnoaccess,
   1451                                        NT_STATUS_ACCESS_DENIED);
   1452                 errno = EACCES;
   1453                 return NULL;
   1454         }

I want you to add level 10 debugs to *your* copy of the samba3.0.20a source code
and add an "else" section to this code that will print out all the values of the
boolean tests we're doing here. If this is happening I need to be able to do
remote debugging...

Jeremy.
Comment 19 Alex Masterov 2005-10-03 21:59:53 UTC
Created attachment 1481 [details]
Yet another sniff

dir V:\1\test.txt
echo xxx >V:\1\test.txt
Comment 20 Alex Masterov 2005-10-03 22:01:28 UTC
Created attachment 1482 [details]
Level 10 log covering above sniff

This debug log was got on my samba while sniffing.
Comment 21 Jeremy Allison 2005-10-03 22:24:19 UTC
The debug level 10 log may finally help. It's late here now, I'll go through
this carefully early tomorrow morning.
Jeremy.
Comment 22 Jeremy Allison 2005-10-04 13:50:32 UTC
I've set dos attribute mapping, set the file to be ARCHIVE only from a
read-write share, then tried the echo >test.txt from the read-only share. I
*always* get access denied. Ok - 2 things. I need to see your entire smb.conf
and I need to know the mount options you've used to mount the drive on your
linux box and I need to know what share you're accessing. I need to have a
*complete* script of how to reproduce this. Looking at the source code I posted
I *still* cannot see how your test is getting past this part of the code :

   1445         if (flags != O_RDONLY && file_existed &&
   1446             (!CAN_WRITE(conn) ||
IS_DOS_READONLY(existing_dos_attributes))) {

Jeremy.

Comment 23 Jeremy Allison 2005-10-04 13:51:10 UTC
Created attachment 1483 [details]
Patch to give me more info

Secondly please add this patch to your source code, recompile and send me the
debug level 10 log from your experiment please.
Jeremy.
Comment 24 Alex Masterov 2005-10-04 19:20:36 UTC
Created attachment 1484 [details]
My samba config

Comments and empty lines removed via
grep -v ^\# smb.conf | grep -v ^\; | egrep -v ^\\s*\$

About server OS: FreeBSD 5.4-STABLE
mount options:
/dev/da1s1a on /shared (ufs, local, soft-updates, acls)

script to reproduce is:
create a file without ro attribute
execute echo xxx >file from a user having no rights to write to file.
Comment 25 Alex Masterov 2005-10-04 19:24:33 UTC
Created attachment 1485 [details]
FreeBSD specific patches used to build my samba.

My samba was built with this patches from freebsd port.
Comment 26 Alex Masterov 2005-10-04 20:19:03 UTC
Created attachment 1486 [details]
Lev 10 log file after patching open.c

Action on client:

echo xxx >V:\1\test.txt

Result: 
The network has responded incorrectly.
Comment 27 Alex Masterov 2005-10-04 20:49:52 UTC
UPS!
Share is not true read-only! It is writable.
But user can not write to file test.txt
I'm terribly sorry!

But question still exists...
Comment 28 Alex Masterov 2005-10-04 21:11:45 UTC
Created attachment 1487 [details]
Sniff echo xxx >file on XP share (R/W share R/O file)

XP as server in similar situation (RO file on RW share).
File test.txt was made non-writable for user by NTFS ACL.

Actions on client:

C:\WINDOWS>attrib V:\1\test.txt
  A	     test.txt	   V:\1\test.txt

C:\WINDOWS>attrib V:\1\test.txt
  A	     test.txt	   V:\1\test.txt

C:\WINDOWS>echo xxx >V:\1\test.txt
File creation error
Comment 29 Jeremy Allison 2005-10-04 22:26:40 UTC
Ok this seems to be the amazing mutating bug. This is at least 3 different
behaviours you've reported on this. The first one I definately fixed with the
patch I added to 3.0.20a.

So what we're looking at now is a different bug.

The actual problem, as I understand it now is that the share *is* in fact
read-write, the file attributes are read/write, but the ACL on the file prevents
a user from writing to the file. Correct ?

If this is *finally* the actual problem then I'll have time to look at this
tomorrow. But first I want to see a confirmation that the case I described above
*is actually* the correct description of the problem.

I've wasted an amazing amount of time trying to reproduce this with a read-only
share and I don't want to waste any more time on a wild goose chase.

So I ask again. is the case I described above an accurate description of the bug ?

Jeremy.
Comment 30 Alex Masterov 2005-10-04 22:50:55 UTC
Yes, you are right.
Problem exists if share is read/write, file has not DOS read-only attribute, but
file is unwritable by user.

Bad description of situation in previous reports is my fault.
I am sorry.
Comment 31 Jeremy Allison 2005-10-05 15:36:09 UTC
Created attachment 1490 [details]
Proposed patch.

Well I'm glad we tracked this one down - it was a bug introduced in the
migration to NTcreate style opens. This patch should fix it. Let me know.
Jeremy.
Comment 32 Alex Masterov 2005-10-05 19:36:04 UTC
Yes! With you patch the problems with echo xxx > file and with opening
unwritable MS Excel file on rw share are fixed!
Thank you!
Comment 33 Scott Wheeler 2005-10-08 06:08:08 UTC
From the looks of it this has been tracked down, but since I'm following up  
from http://bugs.kde.org/show_bug.cgi?id=109451 I thought I'd mention the  
fairly easy way to reproduce this that we've stumbled across.  
  
Using access() to check the write permissions of a read-only file returns that  
it is writable -- i.e. :  
  
bool File::isWritable(const char *file)  
{  
  return access(file, W_OK) == 0;  
}  
  
That returns true on a read-only mounted smbfs.  However then when opening the  
file later on opening in read/write mode fails:  
  
  d->readOnly = !isWritable(file);  
  d->file = fopen(file, d->readOnly ? "r" : "r+");  
  
  if(!d->file)  
    debug("Could not open file " + String(file));  
  
i.e. we do in fact see that debug message.  So access() is returning that it  
is writable while the fopen() call for read/write fails.