Hello Jim, hello Robbie, thanks for your replies. I was very busy with another project and found no time to respond earlier.
From what i have seen in my tests, i'am quite happy with ZFS ACLs and how inheritance seems to work. As i wrote in my initial post, i'am comming from Netware which had full-fledged ACLs for ages and it looks like we could transform our Netware ACLs 1:1 to ZFS ACLs. From what i found on the net, i had the impression that the way of managing ZFS ACLs in a windows environment is to use windows tools, especially MMC and explorer->properties->security but this is a nightmare. Regardless of which local oi-user was used to connect to a share (after rebooting the windows pc), windows mmc didnt only work if the local logged-in win-user was member of the oi-administrators group. oi-users: root, admin, user1 oi-groups: administrators (root,admin), staff (user1) win-users: admin, user1 win-groups: administrators (admin), Users (user1) Current windows user = user1, connect to share as admin: ------------------------------------------------------------ MMC shows oi-users and oi-groups but no access to sessions, files, services, logs. MMC access to oi-group details ok. Shows members (local oi-users). Try to add oi-user fails with 1) MMC not access to oi-user details. Fails with 3) Explorer adding an ACL for a new user alsway fails with 4) Current windows user = admin, connect to share as admin: ------------------------------------------------------------ MMC shows oi-users, oi-groups, sessions, files, services, logs. MMC access to oi-group details ok. Shows members (local oi-users). Try to add oi-user fails with 2) MMC not access to oi-user details. Fails with 3) Explorer adding an ACL for a new user alsway fails with 4) After moving oi-user user1 to oi-group administrators Current windows user = user1, connect to share as admin: ------------------------------------------------------------ MMC shows oi-users, oi-groups, sessions, files, services, logs. MMC access to oi-group details ok. Shows members (local oi-users). Try to add oi-user fails with 2) MMC not access to oi-user details. Fails with 3) Explorer adding an ACL for a new user alsway fails with 4) *(We have a german windows, so i translated the message, hope it fits) 1) MMC prompts for user/password with rights for OI-PC. If you enter an user name, you get constantly "Object .... not found", regardless how you specify the user (<user>, OI-PC\<user>, <user>@OI-PC) If you switch to extend mode, you get a list of available groups. Even that the search path indicates OI-PC, all listed groups are local windows groups. No user object is shown at all. 2) Same procedure as 1) but the list in extend mode includes all local oi-users. If you pick an user from the list, and try to add it, you get "Object returned from object selection is incomplete. Object not processed"* Btw: there is no AD involved here. OI-PC just joint a workgroup using smbadm join -w <workgroup> 3) "Requested directory object is unknown"* 4) "Object named ..... not found"* I start to wonder if this stuff has ever happend to work on openindiana. All samples on the net adhere to Solaris Expess and OpenSolaris. regards Thomas ________________________________ From: Jim Klimov <[email protected]> To: Discussion list for OpenIndiana <[email protected]> Sent: Tuesday, May 22, 2012 7:05 PM Subject: Re: [OpenIndiana-discuss] OI_151a4, ZFS, CIFS - Managaging ACLs from Windows 2012-05-22 20:22, Robbie Crash написал: > I was refeerring to the permission denied errors that shouldn't be > happening. The Unable to delete aspect was just what prompted me to write > the post. > > While I was using the ZFS ACLs I wasn't ever able to make changes via > Windows, and had mixed problems accessing things that had been modified > either by Windows, or directly on the OI server, unless I reset the > permissions with /usr/bin/chmod after the fact. Talk on here and in the OI > room on Freenode led me, and most of the other people I'm aware of, to shut > off ZFS ACLs on all Windows shares. After that, managing the permissions > via Windows was fine. We, for one, use the ZFS ACLs for Windows shares (i.e. to allow several archive admins to upload and manipulate files uploaded or created by anyone, including root locally), but these ACLs were carefully picked by trial and error, and there's a script to set them recursively on all FS objects under the share. However, I don't remember using this script for the past year or two - the inheritable ACL parts worked okay. This is a rather simplistic setup, perhaps - but it suited the environment... Examples of metascripts that set the ACLs: # cd /export/ftp/distribs && for F in *; do chmod -R A=owner@:full_set:d:allow,owner@:full_set:f:allow,group@:rxaARWcs:d:allow,group@:raARWcs:f:allow,user:archadmin:rwxpdDaARWcCos:fd:allow,group:sysadmin:rwxpdDaARWcCos:fd:allow,group:staff:rxaARWcs:d:allow,group:staff:raARWcs:f:allow,everyone@:rxaARWcs:d:allow,everyone@:raARWcs:f:allow $F & done chmod -R A=owner@:rwpdDaARWcCos:f:allow,owner@:rwxpdDaARWcCos:d:allow,group@:rwpdDaARWcCos:f:allow,group@:rwxpdDaARWcCos:d:allow,everyone@:rwpdDaARWcCos:f:allow,everyone@:rwxpdDaARWcCos:d:allow /export/ftp/incoming The ZFS datasets for file archives had default aclmode=groupmask and aclinherit=restricted. Also, the customer's Windows network has an MS AD domain, and the OpenSolaris CIFS server was added to that and some mapid tricks were copypasted from Sun blogs and docs to good effect, to map Windows usernames and groups to those locally defined on the file server (i.e. "Domain Users" = "staff"). There was a plan to merge the two namespaces via LDAP, but that was never completed AFAIK ;) HTH, //Jim Klimov _______________________________________________ OpenIndiana-discuss mailing list [email protected] http://openindiana.org/mailman/listinfo/openindiana-discuss _______________________________________________ OpenIndiana-discuss mailing list [email protected] http://openindiana.org/mailman/listinfo/openindiana-discuss
