ACL issues, Plus, MacOS X stuff

[Matt Benjamin]

I've seen what I take to be Jan's problem using Excel for MacOS X.

It did not occur to me that it was Office specific.  In that case, we 
attempted to use POSIX default ACLs to guarantee access by specific 
individuals--when documents were saved, the mask fields were reset, 
truncating effective rights.

In this case, I was uncertain whether it was permissible to use POSIX 
ACLs directly, but it seems there should be some use cases where this 
would be legitimate.

While I'm at it :)

We also saw two other oddities that I have assumed are known properties 
of the CIFS client in MacOS X 10.3:

1. When we opened documents on a Samba3 share with any application, then 
closed the application entirely, smbstatus reported locks held on those 
files.  Locks were not released until the share was disconnected.  I'm 
inclined to blame the MacOS X CIFS client for this?

2. Apple CIFS client developer(s):  MacOS X users found it annoying that 
the last update time of a file as seen in the finder with resource forks 
(eg, Photoshop file) may not be updated when changes are made to its 
resource forks.  I've seen this reported before, on this list, IIRC.

Matt

Olaf Fra;czyk wrote:

>On Thu, 2004-04-15 at 15:08, Jan Koop wrote:
>  
>
>>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.
>>    
>>
>Hi,
>I saw something similar with Office 2000 with Windows 2000.
>Unfortunately I don't remember details.
>
>Regards,
>
>Olaf
>
>  
>


-- 

Matt Benjamin

The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309