On May 15, 2008, at 3:45 AM, Giuliano Gavazzi wrote:
Dear all,
I have a MacOS X 10.5.2 server acting as a fileserver for mixed
Windows (mainly XP) and Unix (AIX 5.x) clients.
Resources are shared via Samba and NFS.
Clients, at the application level, are a mix of Catia V4 and V5,
some CAM systems (Surfcam and Catia) plus the odd Windows application.
Access policy is done by defining groups for each resource (a
hierarchy under a certain directory), a group for writing and one
for reading. Everyone (intended as the groups of all users) access i
denied.
My /etc/smb.conf differs from the standard only by (default values
left commented out):
; vfs objects = darwinacl,darwin_streams
vfs objects = darwinacl
; stream support = yes
stream support = no
; ea support = yes
ea support = no
; enable core files = no
enable core files = yes
acl check permissions = no
max disk size = 102400
I set "Inherit Permission from Parent " in the protocol options from
ServerAdmin - Sharing.
The PROBLEM (sorry if this is not totally clear, but the
applications involved are many and their behaviour interfere in many
ways):
In short ACL and unix permissions interfere in a way that is
application dependent.
I cannot find a way to make the applications interact with the file
server in a way that is consistent with the permissions I set. I
would expect ACL to take precedence over Unix permission flags and
in particular ACL to be set on the server and not touched by the
client, but this is not so.
as you can see I set the unix flag to 000. Why? Because if they were
not set so once a file had been opened modified and saved by Catia5
it would acquire new ACL that were reflecting these unix
permissions, and the permissions in turn would be set to 000.
If the darwinacl module thinks that an ACE can be fully represented by
the Unix permissions bits, it will set the corresponding bits and
remove the ACE. This gets a little complex :(
In this instance Catia5 (or the server?) would then reorder the ACL
in a canonical order, so that the everyone deny rule would appear
first. This happens at some point during file saving (that, in
Catia5, is a complex process), resulting in a failure as the file
becomes inaccessible.
MacOSX Finder on a client acts in another way instead: when
accessing a share like this it will not allow access... even if the
ACL would allow it (this is incorrect in my view, as ACL should take
precedence). Terminal will not exhibit this problem.
I have a solution after examining a number of symptoms:
as Catia will turn unix flags into ACL and clear the flags, and at
the same time the ACL will be canonically reordered, do not add the
"2: group:everyone deny..." ACE, instead set file unix mode to 640.
When the file will be accessed and saved its mode will be set to
000, and the ACL set to emulate this, without the wrong reordering.
Directories are set as 750, as, I suppose, Catia has no effect on
them (to be verified).
The ACL are like the above without the #2. After Catia5 save they
will acquire the extra (this is for a file):
Strangely enough Windows Explorer (or whatever their Finder is
called) and other Windows applications, respect the ACLs and act as
expected (opening, saving, deleting). Haven't tried with Office apps
yet...
Windows applications generally ignore permissions and simply try to
perform the operation. Finder attempts to show you the access you have
(by using the access(2) call). The OS X smbfs client only knows how to
deal with ACLs when it is joined to Active Directory, so if your case,
it is evaluating the effective access solely from the Unix
permissions. Terminal apps behave more like Windows apps in this
respect.
There are still outstanding problems as for instance an ACL that
would deny chmod has no effect (I verified this while trying to sort
the problem above), as the user with write access can instead change
the mode.
I hope this will be of help to others. I can give more info if
required.
Any comments are welcome!
Giuliano
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macos-x-server mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/macos-x-server/email@hidden
