Reproducible bug in 3.0.2a ACL support

[s_abate at ciudad.com.ar]

First, sorry my english

Maybe the problem is the way that Microsoft Office's applications treat the
files. When you open a file, Word/Excel create a temporary one while you
work with it, and when you save the file, Word/Excel delete the original one
and rename the temporary one with the original's name, setting the editing
user as the owner of the file, also setting the default ACL's.

In Spanish:

Tal vez el problema sea la forma en que las aplicaciones Office tratan a los
archivos. Cuando se abre un archivo, Word/Excel crea un archivo temporario
mientras se trabaja con el, y cuando se salva el archivo, Word/Excel elimina
el original y renombra el temporal con el mismo nombre que el anterior,
seteando como owner del archivo al usuario que lo está modificando, y
seteando también los ACL por defecto.

Sebastián Abate

-----Mensaje original-----
De: samba-technical-bounces+s_abate=ciudad.com.ar at lists.samba.org
[mailto:samba-technical-bounces+s_abate=ciudad.com.ar at lists.samba.org]En
nombre de Jan Koop
Enviado el: Jueves, 15 de Abril de 2004 10:09 a.m.
Para: samba-technical at lists.samba.org
Asunto: Reproducible bug in 3.0.2a ACL support


Hi list,

this is the situation:

Basics:
RH AS 3.0 Update 1
Kernel  2.4.21-9.0.1.ELsmp
Samba 3.0.2a
Filesystem: ext3
Mount options: acl,noatime

Config:
Role: PDC
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"

getfacl output:
# file: example.doc
# owner: alice
# group: users
user::rwx
group::r-x
group:word:rwx
mask::rwx
other::---

alice and bob are in the additional group "word":
[root at smb01 testdir]# id alice
uid=1000(alice) gid=513(users) groups=513(users),1192(word)
[root at smb01 testdir]# id bob
uid=1001(bob) gid=513(users) groups=513(users),1192(word)

Group mapping and such is correctly set up.

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
user::r-x
user:alice:rwx
group::rwx
group:word:rwx
mask::rwx
other::---

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.

Overview:
Office 97 under XP : BUG
Office 97 under 9x : OK
Office XP/2k3 under XP: OK
Office XP/2k3 under 9x : ??? ;D

I haven't tried any Windows 2000 or Office 2000 versions, as well as no
NT or XP without SP1 Office 97 has SR-2a.
This occurred in a similar setup using XFS w/ ACLs as well.

Excuse my harsh subject, I know it could be a bug in Office 97, but
buying 150+ Office XP licenses is not possible. And I am almost sure
that it won't happen when opening a file on a Windows Server.

So my guess is: Office 97 running under XP is trying to do something to
the NT ACLs it gets from the server. At some point this fails and leaves
this mess. Maybe Windows servers have some kind of workaround for that,
but I will look into it later on today when a test setup is up.

I tried a lot forcing the file mode and security mask but it didn't help.

I saw at least two guys stating this problem on this list with no
solution. I'm not sure if this bug is known or if it even was fixed in
3.0.3 already.

If think you can help me please feel free to ask me anything you want to
know, or request more detailed information/traces, even access to a test
setup.

Thanks guys,

Jan