Michael Anderson wrote:
Aha! After 'c)' above, things are looking better:
Excellent.
Interesting:
when I copy a file from the CIFS share to the windows desktop, the
user's unix GID disappears from the permissions, and the 'SYSTEM'
group appears instead.
I believe that most Windows copy programs do not attempt to preserve the
ACL.
If create a file on Windows, there exist windows permissions for the
user and SYSTEM, the unix group is 'nobody', and the unix owner is no
longer owner, but a generic user with certain ACL rights to the file
and can read, write, but not delete files. So the perms look like this
on opensolaris:
# ls -vl created_on_windows.txt
----------+ 1 vuser1 2147524611 0 Mai 26 00:03
created_on_windows.txt
0:user:vuser1:read_data/write_data/append_data/read_xattr/write_xattr
/execute/delete_child/read_attributes/write_attributes/delete
/read_acl/write_acl/write_owner/synchronize:allow
1:group:2147483648:read_data/write_data/append_data/read_xattr
/write_xattr/execute/delete_child/read_attributes/write_attributes
/delete/read_acl/write_acl/write_owner/synchronize:allow
You might want to add "ad" to your /etc/nsswitch.conf passwd and group
lines, so that ls -l can show you the Windows users and groups instead
of the big numbers like 2147524611. See ad(5).
You might try
$ idmap show -cv gid:2147524611 winname
to confirm what the group setting is on that file. (Probably the answer
is Domain Users.)
I suppose I have to walk the share with inheritable 'owner@'
permissions, or something like that?
That might help ls -l produce good-looking permission values. It also
depends on what semantics you want: do you want the access control to
apply to the current owner of the file (which is usual UNIX behavior) or
do you want it to apply to some specific user (which is usual Windows
behavior)?
There are two recent CRs that are relevant to this behavior:
6899409 Preserve owner@/group@ across SMB
UNIX has a concept of an access control entry (the rwx------ bits in
traditional UNIX) that applies to the current owner of a file, whoever
that might be. Windows doesn't have this concept. Before build 132,
for Windows purposes we would translate the "owner" permissions into an
access control entry that specified the current owner of the file. That
looked pretty much right, but caused a problem: if the Windows system
wrote that access control list back to the server, the effect would be
to change that access control entry from "the current owner" to some
specific user, changing its semantics. (Automatically converting it
back to a "current owner" entry would cause a similar problem.)
Starting in build 132, we report a special "Current owner" user to
Windows, so that the semantics are preserved when the Windows system
makes changes. (Similar comments apply to "current group".)
6923083 ZFS/NFS/SMB ACL interoperability changes
In ZFS, all access control is through access control lists. There are
no traditional UNIX permissions stored; UNIX permissions are synthesized
when needed by processing the access control lists. Before build 139,
that algorithm considered only "current owner" and "current group"
entries when synthesizing traditional UNIX permissions. That often
resulted in permissions that looked like "---------" even when the owner
of the file had full access, because that access was granted explicitly
to that user rather than to "the current owner". Starting in build 139,
access control entries that refer specifically to the user who happens
to own the file are also considered. Note: Since the actual access
control checks use the access control list, these "bad" permissions
reports largely did not affect access; they just worried humans looking
at them. (Again, similar comments apply to "current group".)
Note that these two can combine to turn a "current owner" access control
entry into a specific-user entry, and thus yield a "---------"
permission list.
But how do I make newly created files belong to the unix primary group?
To which UNIX primary group do you refer?
They probably belong to the Windows primary group of the Windows user.
Perhaps you want them to belong to the UNIX primary group of the UNIX user?
That is:
If you have
- a UNIX user UU, whose primary group is UG1
- a Windows user WU, whose primary group is WG
- WU is mapped to UU
- WG is mapped to UG2
Before build 137, if WU creates a file, we consider the user and group
separately, mapping WU to UU and WG to UG2. The file thus ends up with
owner=UU and group=UG2.
That's not unreasonable, but it's probably not what a UNIX-centric user
expects, because it's not what you would have gotten if UU created the
file. CR 6906874 "Automatic primary group mapping based on user
mapping", delivered in build 137, changes this behavior. With the new
behavior, for the purposes of the group setting of newly created files
and directories, we use the UNIX user's primary group - UG1 in this
case. (It's not relevant here, but we continue to use WG and thus UG2
when processing the Windows-style CREATOR GROUP access control list
entry, since that's what a Windows-centric user would expect.)
Note that Windows-centric users are unlikely to care about the file's
group setting, and UNIX-centric users are unlikely to care about the
behavior of CREATOR GROUP.
Does that all make sense?
Thanks again for all the help,
My pleasure.
_______________________________________________
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss