Quoting Jordan Brown <jordan.br...@oracle.com>:
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).
Ah, yes, right.
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.)
Right again.
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?
Indeed.
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?
Yes, it does. We are a very Unix-centric shop, and have been running
samba with msSFU/winbind without acls. I would like to make the
transition to ZFS-CIFS/ACL as transparent as possible to our users,
who are used to newly created files belonging to the primary unix
group of the unix user, regardless of whether they created on windows
or unix. They also expect to see the permissions of the mapped unix
user when they do a ls -l in Unix. That is when vus...@elego.de
creates a file on windows, he expects to see something like:
-rwxr----- 1 vuser1 Gvuser1
on his NFS mount.
If I understand correctly, these behaviors have been incorporated into
the newest builds.
Thanks again for all the help,
My pleasure.
--
Michael Anderson
IT Services & Support
elego Software Solutions GmbH
Gustav-Meyer-Allee 25
Building 12.3 (BIG) room 227
13355 Berlin, Germany
phone +49 30 23 45 86 96 michael.anderson at elegosoft.com
fax +49 30 23 45 86 95 http://www.elegosoft.com
Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin
Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194
_______________________________________________
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
