The Samba-Bugzilla – Bug 1280
Office 97 (e.g. Word) changing ACLs to an unusable state
Last modified: 2005-05-23 13:50:06 UTC
This bug is not a duplicate of #1077 since it was reproduced in samba 3.0.0rc4,
3.0.2, 3.0.2a, 3.0.3pre2, and 3.0.3rc1
RH AS 3.0 Update 1
Mount options: acl,noatime
passdb backend = ldapsam:ldapi://%2fvar%2frun%2fldapi/
Everything works so far. Now the problem:
We have a file "example.doc" which is a word 8 (word 97) file.
The file is owned by "alice", group "users"
# file: example.doc
# owner: alice
# group: users
alice and bob are in the additional group "word":
[root@smb01 testdir]# id alice
uid=1000(alice) gid=513(users) groups=513(users),1192(word)
[root@smb01 testdir]# id bob
uid=1001(bob) gid=513(users) groups=513(users),1192(word)
Alice can use the file without any problems. Now bob comes along, opens the
file, changes it and writes to it.
This is what happens to the ACLs/ownership:
Bob takes ownership of the file, alice is placed on the ACL with her old rights
(rwx) and bob's user write bit is removed.
ACL output after the event:
# file: example.doc
# owner: bob
# group: users
This results in the "write protected" flag being set on the client when looking
at it in "Properties...", thus enabling the client to only open the file read
only (as bob that is).
I was able to track down the problem to the combination of Office 97 running
under Windows XP SP1. It does not occur using Office 97 under Windows 9x nor
using Office XP / Office 2003 under Windows XP SP1.
Office 97 under XP : BUG
Office 97 under 9x : OK
Office XP/2k3 under XP: OK
I haven't tried any Windows 2000 or Office 2000 versions, as well as no NT or XP
without SP1. Office 97 has been tested in the original version, w/ SR-1, and SR-2a.
This occurred in a similar setup using XFS w/ ACLs as well.
I reproduced the exact setup with a Windows 2000 Server. The file operation
worked cleanly there.
I did a little bit of further research of that behavior.
It occurs to me that the group ownership is changed during the file operation as
well. So in alice/bob's case the owning group is set to their primary group (users).
The permissions of the owning user is set to the maximum effective permission
the user is granted via his primary group membership, that's why in the stated
case the write bit is not set, that's where it comes from.
If the primary group of the user is not the owning group, the file is chgrp'ed
and the former owning group is placed on the ACL just as the former owner.
If the group isn't listed in the ACL and isn't the owning group, the permission
bits are copied from the "other" permission (o::) and placed on user and group
(u::,g::) entries, whilst the "read" bit is always set on the user's perms.
Well... nobody seems to care... too bad! Very disappointing.
don't be disappointed. There are many other bugs which have to be taken care of
and there's only little time :(.
I have a case where that problem is reproducable.
*** Bug 1395 has been marked as a duplicate of this bug. ***
i have reproduced the same behaviour with xfs acl's + samba 3.0.7 + msoffice2k
I have reproduced the bug on win2K with word 97 !
samba 3.0.7 on RedHat Linux 3 update 3
It seems like if Word would like to delete modifier user's right to put the
rights of the creator user.
but the modifier user is in the unix rights not in ACL so they can't be deleted !
I open incident to my redhat support and IDEALX support.
(In reply to comment #6)
> I open incident to my redhat support and IDEALX support.
nobody want to take bug in charge !
"this is a word bug !"
this is a pity for a so used soft !
(In reply to comment #7)
How can it be a word bug, if it does not occur using a Windows 2000 Server
(which I tested)?
please retest 3.0.11 and repoen if the issue still exists.
I've reset the version to 3.0.7 (originally report
against 3.0.3pre1) based on your comments.
rrenard (irc) says still an issue and will add some comments
Jeremy, could you take a look at this one when you get a chance.
Created attachment 1127 [details]
network trace when pressing the save button in word
With 3.0.13 the problem is worse for the user, Word97 cannot save the file under
its original name. Data is there but as a backup file.
The original file is renamed as a temp file, a new temp file is created, data
written to it, but somewhere it is set as read only. word seems to try to change
its state to rw, which does not work, then it gives-up asking the user to save
the file under the temporary file name (which does not work either).
The only workaround is to save the file under a different name.
tested with XP-sp2 and Word97-sr2
Excel97 shows no problems
good workaround for those who didn't know this (like me):
force create mode = 0660
lot of thanx to Clark Mills
This is a duplicate bug to 2346. I have finally fixed this in SVN source.
Please see the patch attached to that bug for the patch.
*** This bug has been marked as a duplicate of 2346 ***