Re: [zfs-discuss] ZFS ACLs/Samba integration
On Fri, 2008-03-14 at 18:11 -0600, Mark Shellenbaum wrote: I think it is a misnomer to call the current implementation of ZFS a pure ACL system, as clearly the ACLs are heavily contaminated by legacy mode bits. Feel free to open an RFE. It may be a tough sell with PSARC, but maybe if we have enough customer requests maybe they can be won over. It is always wrong to have a mental model of PSARC as a monolithic entity. I suspect at least some of the membership would be interested in this sort of extension and it shouldn't be that hard to sell if it's not the default behavior and it's clearly documented that turning it on (probably on a fs-by-fs basis like every other zfs tunable) takes you out of POSIX land. - Bill ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS ACLs/Samba integration
On Mon, 17 Mar 2008, Bill Sommerfeld wrote: I suspect at least some of the membership would be interested in this sort of extension and it shouldn't be that hard to sell if it's not the default behavior and it's clearly documented that turning it on (probably on a fs-by-fs basis like every other zfs tunable) takes you out of POSIX land. I was actually rereading the Solaris ZFS Administration Guide; based on it the behavior I want should already be available: The ZFS file system includes two property modes related to ACLs: aclinherit - This property determines the behavior of ACL inheritance. Values include the following: passthrough - For new objects, the inheritable ACL entries are inherited with no changes made to them. This mode, in effect, disables secure mode. aclmode - This property modifies ACL behavior whenever a file or directory's mode is modified by the chmod command or when a file is initially created. Values include the following: passthrough - For new objects, the inheritable ACL entries are inherited with no changes made to them. This documentation would seem to indicate that if both aclinherit and aclmode are set to passthrough, then the inheritable ACL entries are inherited with no changes made to them. However, as I originally posted, the inheritable ACL entries I configured are being munged. Based on the documentation, this behavior is broken. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | [EMAIL PROTECTED] California State Polytechnic University | Pomona CA 91768 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS ACLs/Samba integration
Paul B. Henson wrote: On Mon, 17 Mar 2008, Bill Sommerfeld wrote: I suspect at least some of the membership would be interested in this sort of extension and it shouldn't be that hard to sell if it's not the default behavior and it's clearly documented that turning it on (probably on a fs-by-fs basis like every other zfs tunable) takes you out of POSIX land. I was actually rereading the Solaris ZFS Administration Guide; based on it the behavior I want should already be available: The ZFS file system includes two property modes related to ACLs: aclinherit - This property determines the behavior of ACL inheritance. Values include the following: passthrough - For new objects, the inheritable ACL entries are inherited with no changes made to them. This mode, in effect, disables secure mode. aclmode - This property modifies ACL behavior whenever a file or directory's mode is modified by the chmod command or when a file is initially created. Values include the following: passthrough - For new objects, the inheritable ACL entries are inherited with no changes made to them. This documentation would seem to indicate that if both aclinherit and aclmode are set to passthrough, then the inheritable ACL entries are inherited with no changes made to them. However, as I originally posted, the inheritable ACL entries I configured are being munged. Based on the documentation, this behavior is broken. The documentation in the admin guide isn't quite correct. I will go ahead and do a fastrack to get the behavior that many people want. Basically, if inheritable ACEs are present for owner@, group@, everyone@ then the inherited ACE permissions will override the requested mode of the application. If no inheritable ACEs are present for owner@, group, or everyone@ then the mode will be used. -Mark ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS ACLs/Samba integration
On Mon, 17 Mar 2008, Mark Shellenbaum wrote: I will go ahead and do a fastrack to get the behavior that many people want. Basically, if inheritable ACEs are present for owner@, group@, everyone@ then the inherited ACE permissions will override the requested mode of the application. If no inheritable ACEs are present for owner@, group, or everyone@ then the mode will be used. *Sweet*!!! That sounds perfect! Is that something that might be backported to production Solaris 10 in a patch? Or something that would have to wait for an update release? We are currently prototyping an NFSv4/Samba file services implementation for our campus, management is requiring official support for the OS so OpenSolaris isn't really an option; but I don't think we can deploy without this fix. Thanks much... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | [EMAIL PROTECTED] California State Polytechnic University | Pomona CA 91768 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS ACLs/Samba integration
Paul B. Henson wrote: On Mon, 17 Mar 2008, Mark Shellenbaum wrote: I will go ahead and do a fastrack to get the behavior that many people want. Basically, if inheritable ACEs are present for owner@, group@, everyone@ then the inherited ACE permissions will override the requested mode of the application. If no inheritable ACEs are present for owner@, group, or everyone@ then the mode will be used. *Sweet*!!! That sounds perfect! Is that something that might be backported to production Solaris 10 in a patch? Or something that would have to wait for an update release? We are currently prototyping an NFSv4/Samba file services implementation for our campus, management is requiring official support for the OS so OpenSolaris isn't really an option; but I don't think we can deploy without this fix. Thanks much... No guarantees, but I think it should be back portable to Solaris 10. -Mark ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS ACLs/Samba integration
On Thu, Mar 13, 2008 at 11:33:57AM +, Darren J Moffat wrote: Paul B. Henson wrote: I'm currently prototyping a Solaris file server that will dish out user home directories and group project directories via NFSv4 and Samba. Why not the in kernel CIFS server ? E.g., how would one mimic: [office] comment = office path = /export/vol1/office valid users = @office force group = office create mode = 660 directory mode = 770 ... We already lost this functionality with the introduction of the NFSv4 ACL crap on ZFS and earned a lot of hate you feedbacks. Anyway, most users and staff switched/switching over to windows (we do not support Linux yet and Solaris is wrt. desktop at least 5 years behind the scene), so the last 5% of *x users need to live with it. However, if we would switch to Solaris CIFS (which AFAIK can not accomplish, what is required) we would have no friends anymore ... Regards, jel. -- Otto-von-Guericke University http://www.cs.uni-magdeburg.de/ Department of Computer Science Geb. 29 R 027, Universitaetsplatz 2 39106 Magdeburg, Germany Tel: +49 391 67 12768 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS ACLs/Samba integration
Jens Elkner wrote: On Thu, Mar 13, 2008 at 11:33:57AM +, Darren J Moffat wrote: Paul B. Henson wrote: I'm currently prototyping a Solaris file server that will dish out user home directories and group project directories via NFSv4 and Samba. Why not the in kernel CIFS server ? E.g., how would one mimic: [office] comment = office path = /export/vol1/office valid users = @office force group = office create mode = 660 directory mode = 770 ... We already lost this functionality with the introduction of the NFSv4 ACL crap on ZFS and earned a lot of hate you feedbacks. Anyway, most users and staff switched/switching over to windows (we do not support Linux yet and Solaris is wrt. desktop at least 5 years behind the scene), so the last 5% of *x users need to live with it. However, if we would switch to Solaris CIFS (which AFAIK can not accomplish, what is required) we would have no friends anymore ... Regards, jel. You mean something like this. # zpool create sandbox c0t3d0 # zfs set sharesmb=on sandbox I then set this ACL on the directory # ls -dV /sandbox drwxrwxrwx+ 2 root root 3 Mar 14 08:27 /sandbox group@:rw-pdDaARWcCos:f--:allow owner@:rw-pdDaARWcCos:f--:allow owner@:--:---:deny owner@:rwxp---A-W-Co-:---:allow group@:--:---:deny group@:rwxp--:---:allow everyone@:---A-W-Co-:---:deny everyone@:rwxp--a-R-c--s:---:allow Then I created a file from a windows client I have this idmap rule setup # idmap list add winuser:[EMAIL PROTECTED] unixuser:marks # ls -V New* -rw-rw+ 1 marks2147483650 0 Mar 14 08:28 New Wordpad Document.doc group@:rw-pdDaARWcCos:--I:allow owner@:rw-pdDaARWcCos:--I:allow # idmap dump usid:S-1-5-21-940912991-1138591764-871648236-1138 == uid:2147483649 gsid:S-1-5-21-940912991-1138591764-871648236-513== gid:2147483650 gsid:S-1-5-11 == gid:2147483651 gsid:S-1-5-2== gid:2147483652 usid:S-1-5-21-940912991-1138591764-871648236-1119 == uid:76928 gsid:S-1-5-21-2169176303-1867137939-2363023632-3371165004-2147483658 == gid:10 this behavior is only possible from a Windows client. When creating files from unix the POSIX rules apply and the requestors mode must be honored, which results in the owner@, group@, and everyone@ entries always being set on the files ACL. -Mark ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS ACLs/Samba integration
On Fri, 14 Mar 2008, Jens Elkner wrote: We already lost this functionality with the introduction of the NFSv4 ACL crap on ZFS and earned a lot of hate you feedbacks. I was actually looking forward to ZFS ACLs, as they should have been much more compatible with Samba/Windows clients. Unfortunately, so far it looks like the implementation results in a lot of breakage. I'm still trying to understand why the ZFS ACLs behave the way they do; but I fear they are not going to work out the way I hoped :(. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | [EMAIL PROTECTED] California State Polytechnic University | Pomona CA 91768 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS ACLs/Samba integration
Paul B. Henson wrote: On Fri, 14 Mar 2008, Mark Shellenbaum wrote: this behavior is only possible from a Windows client. When creating files from unix the POSIX rules apply and the requestors mode must be honored, which results in the owner@, group@, and everyone@ entries always being set on the files ACL. It's one thing to feature POSIX compatibility; it's another to force it. I was hoping with a pure ACL implementation to be able to disregard the legacy POSIX mode bits baggage and have ACLs handled sanely. It doesn't look like I can achieve that though :(. Upon creation, a brand-new ZFS file system has the following ACL: drwxr-xr-x 2 root sys2 Mar 14 14:42 . owner@:--:--:deny owner@:rwxp---A-W-Co-:--:allow group@:-w-p--:--:deny group@:r-x---:--:allow everyone@:-w-p---A-W-Co-:--:deny everyone@:r-x---a-R-c--s:--:allow Given that in my understanding any permission not explicitly allowed is denied by default, what is the purpose of the explicitly listed deny components? They in no way alter the effective permissions, and result in a Windows client accessing the permissions via samba issuing an error regarding the ordering. That is not correct. The deny entries are necessary for POSIX semantics. In POSIX are only allowed to pick up permissions from the owner, group or other class. You can't pick up part of the permissions you are looking for from the group class and then some more from the other class. The creation of a file in the file system results in the following ACL: -rw-r--r-- 1 root root 0 Mar 14 14:43 foo owner@:--x---:--:deny owner@:rw-p---A-W-Co-:--:allow group@:-wxp--:--:deny group@:r-:--:allow everyone@:-wxp---A-W-Co-:--:deny everyone@:r-a-R-c--s:--:allow Again, it seems the deny components are extraneous, serving only to complicate the ACL. So, I modified the ACL to look as follows, resulting in the exact same effective permissions, but much simpler to parse: -rw-r--r-- 1 root root 0 Mar 14 14:43 foo owner@:rw-p---A-W-Co-:--:allow group@:r-:--:allow everyone@:r-a-R-c--s:--:allow Note that the above file still has a trivial ACL, as indicated by the lack of + in the permission bits. That is actually a bug that was recently fixed. Now, let's say I wanted to remove group and other readability from that file via chmod og-r foo -- that results in: -rw---+ 1 root root 0 Mar 14 14:43 foo owner@:---A-W-Co-:--:allow group@:--:--:allow everyone@:--a-R-c--s:--:allow owner@:--x---:--:deny owner@:rw-p---A-W-Co-:--:allow group@:rwxp--:--:deny group@:--:--:allow everyone@:rwxp---A-W-Co-:--:deny everyone@:--a-R-c--s:--:allow WTF? Now there are three entries each for owner, group and everyone. Three unnecessary deny ACE's have been added, two of the owner allow entries overlap, there is a group allow ACE permitting nothing. And oddly, a file that started with a trivial ACL, and was modified via mode bit changes, suddenly has a nontrivial ACL. That just seems broken... Moving on to inherited permissions, lets say I wanted to create a directory writable by the group, with newly created files and subdirectories also writable by the group. I thought the following ACL should allow that: drwxrwxr-x+ 2 root root 2 Mar 14 14:46 groupw everyone@:--:f-i---:allow group@:rw:f-i---:allow owner@:rw:f-i---:allow owner@:rwxp---A-W-Co-:-d:allow group@:rwxp--:-d:allow everyone@:r-x---a-R-c--s:-d:allow Creating a new file in that directory results in: -rw-r--r--+ 1 root root 0 Mar 14 14:53 groupw/file everyone@:--:--:allow group@:--:--:allow owner@:--:--:allow owner@:--x---:--:deny owner@:rw-p---A-W-Co-:--:allow group@:-wxp--:--:deny group@:r-:--:allow everyone@:-wxp---A-W-Co-:--:deny everyone@:r-a-R-c--s:--:allow Thats because the requesters mode must be honored. You can't disregard the mode the application requests and the ACL needs to be altered to match the mode. That why the three entries are basically nulled out, but the ACEs are left in place in case you want to change them later. What is
Re: [zfs-discuss] ZFS ACLs/Samba integration
On Fri, 14 Mar 2008, Mark Shellenbaum wrote: That is not correct. The deny entries are necessary for POSIX semantics. In POSIX are only allowed to pick up permissions from the owner, group or other class. You can't pick up part of the permissions you are looking for from the group class and then some more from the other class. Ah, I was interpreting them from the standpoint of an NFSv4 ACL, not from a legacy POSIX perspective. Note that the above file still has a trivial ACL, as indicated by the lack of + in the permission bits. That is actually a bug that was recently fixed. What was fixed? That the ACL would no longer be considered trivial? Thats because the requesters mode must be honored. You can't disregard the mode the application requests and the ACL needs to be altered to match the mode. That why the three entries are basically nulled out, but the ACEs are left in place in case you want to change them later. Hmm... What's the point of having the ability to inherit ACL entries if you can't actually control the permissions on new files and directories that will be created? Why did my ACE's that were applicable to the parent directory and marked inheritable be split into two separate ACE's, one inherit only and one applicable? That seems redundant and overly complicates the ACL. That necessary for effective propagation of ACEs. That way the ACE is propagated down as it was set at the first place the ACE was set. Ok, if I understand you correctly, they are split such that you can modify the ACL pertaining to the actual directory object without modifying the ACL that will be inherited by future child objects? That makes sense. What I would really like to see is a mode that completely ignores umask/mode bits and simply applies the inherited ACL with no modification or complication. I don't see any way to do that? No such mode exists. Am I mistaken or confused in my thought that such a mode would be highly desirable? I would like to be able to configure permissions, particularly inherited permissions, such that they would be fully defined by the ACL, and not modified in unknown ways by whatever umask happened to be in effect when the file or directory was created. I would also like to be able to maintain ACLs via either UNIX commands or from a CIFs client and have them stay compatible. I think it is a misnomer to call the current implementation of ZFS a pure ACL system, as clearly the ACLs are heavily contaminated by legacy mode bits. Thanks for the response... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | [EMAIL PROTECTED] California State Polytechnic University | Pomona CA 91768 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS ACLs/Samba integration
Paul B. Henson wrote: On Fri, 14 Mar 2008, Mark Shellenbaum wrote: That is not correct. The deny entries are necessary for POSIX semantics. In POSIX are only allowed to pick up permissions from the owner, group or other class. You can't pick up part of the permissions you are looking for from the group class and then some more from the other class. Ah, I was interpreting them from the standpoint of an NFSv4 ACL, not from a legacy POSIX perspective. Note that the above file still has a trivial ACL, as indicated by the lack of + in the permission bits. That is actually a bug that was recently fixed. What was fixed? That the ACL would no longer be considered trivial? No longer considered trivial. Thats because the requesters mode must be honored. You can't disregard the mode the application requests and the ACL needs to be altered to match the mode. That why the three entries are basically nulled out, but the ACEs are left in place in case you want to change them later. Hmm... What's the point of having the ability to inherit ACL entries if you can't actually control the permissions on new files and directories that will be created? Inheriting ACEs works better if you don't use owner@, group@ or [EMAIL PROTECTED] Those ACEs affect the mode of the file Why did my ACE's that were applicable to the parent directory and marked inheritable be split into two separate ACE's, one inherit only and one applicable? That seems redundant and overly complicates the ACL. That necessary for effective propagation of ACEs. That way the ACE is propagated down as it was set at the first place the ACE was set. Ok, if I understand you correctly, they are split such that you can modify the ACL pertaining to the actual directory object without modifying the ACL that will be inherited by future child objects? That makes sense. What I would really like to see is a mode that completely ignores umask/mode bits and simply applies the inherited ACL with no modification or complication. I don't see any way to do that? No such mode exists. Am I mistaken or confused in my thought that such a mode would be highly desirable? I would like to be able to configure permissions, particularly inherited permissions, such that they would be fully defined by the ACL, and not modified in unknown ways by whatever umask happened to be in effect when the file or directory was created. I would also like to be able to maintain ACLs via either UNIX commands or from a CIFs client and have them stay compatible. I think it is a misnomer to call the current implementation of ZFS a pure ACL system, as clearly the ACLs are heavily contaminated by legacy mode bits. Feel free to open an RFE. It may be a tough sell with PSARC, but maybe if we have enough customer requests maybe they can be won over. Thanks for the response... ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS ACLs/Samba integration
Paul B. Henson wrote: I'm currently prototyping a Solaris file server that will dish out user home directories and group project directories via NFSv4 and Samba. Why not the in kernel CIFS server ? -- Darren J Moffat ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS ACLs/Samba integration
On Wed, 12 Mar 2008, Roy Butler wrote: a NetApp could do some kind of mapping to satisfy your idea, but of even that I'd be skeptical. We eval'd a netapp box. ACL mapping on netapp sucks. You really need to either use unix or windows privs, not both. I run a few NetApp boxes, must admit I've never noticed the ACL mapping sucking before. How does yours suck? This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS ACLs/Samba integration
On Mar 13, 2008, at 07:33, Darren J Moffat wrote: Paul B. Henson wrote: I'm currently prototyping a Solaris file server that will dish out user home directories and group project directories via NFSv4 and Samba. Why not the in kernel CIFS server ? It's an option, but not everyone wants to / can run OpenSolaris / Nevada. It will be very useful once it's in Solaris 'proper' though. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS ACLs/Samba integration
David Magda wrote: On Mar 13, 2008, at 07:33, Darren J Moffat wrote: Paul B. Henson wrote: I'm currently prototyping a Solaris file server that will dish out user home directories and group project directories via NFSv4 and Samba. Why not the in kernel CIFS server ? It's an option, but not everyone wants to / can run OpenSolaris / Nevada. It will be very useful once it's in Solaris 'proper' though. The in-kernel CIFS server _might not_ get backported to a Solaris 10 update release. If that's the case then you might be waiting a while until the next release happens. James C. McPherson -- Solaris kernel software engineer, system admin and troubleshooter http://www.jmcp.homeunix.com/blog http://blogs.sun.com/jmcp Find me on LinkedIn @ http://www.linkedin.com/in/jamescmcpherson ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS ACLs/Samba integration
On Thu, 13 Mar 2008, Darren J Moffat wrote: Paul B. Henson wrote: I'm currently prototyping a Solaris file server that will dish out user home directories and group project directories via NFSv4 and Samba. Why not the in kernel CIFS server ? An official supported version of Solaris is a project requirement. Unless you guys want to start offering support contracts for opensolaris ;), that's not an option. Presumably when the in-kernel server becomes officially supported (whether in an update release or Solaris 11) there will be a transition plan for people that have been using samba. I'm more concerned about my ACL questions than Windows file sharing, I think Samba will work out fine for that. I haven't seen any responses on those; I guess I'll have to open up a support ticket and see if I can get any enlightenment via that route. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | [EMAIL PROTECTED] California State Polytechnic University | Pomona CA 91768 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS ACLs/Samba integration
Paul B. Henson wrote: On Thu, 13 Mar 2008, Darren J Moffat wrote: Paul B. Henson wrote: I'm currently prototyping a Solaris file server that will dish out user home directories and group project directories via NFSv4 and Samba. Why not the in kernel CIFS server ? An official supported version of Solaris is a project requirement. Unless you guys want to start offering support contracts for opensolaris ;), that's not an option. Presumably when the in-kernel server becomes officially supported (whether in an update release or Solaris 11) there will be a transition plan for people that have been using samba. You can get support for SXDE. Perhaps you already have it. http://www.sun.com/service/subscriptions/sxde.xml -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS ACLs/Samba integration
On Thu, 13 Mar 2008, Rocky wrote: I run a few NetApp boxes, must admit I've never noticed the ACL mapping sucking before. How does yours suck? It's been almost a year since we evaluated Netapp, I'm a little hazy on the details. Basically, NetApp has three different ideas of the permissions for a file or directory; UNIX mode bits, NFSv4 ACL, and CIFS ACL. You can set a particular share to either UNIX mode, windows mode, or mixed mode. In UNIX mode, any access from the Windows side has that identity converted to a UNIX identity and permission checked against the UNIX permissions. In windows mode, vice versa. In either of those two modes, you can only change permission from the native side; ie, Windows clients couldn't change permissions for shares set to UNIX mode. Mixed mode, IIRC, for access from UNIX, and Windows permissions for access from Windows. However, unless I must remember, changing the permissions from one side overwrote the permissions on the other with a translated version. Like I said, it's been a while since I looked at it, but I distinctly recall that in an environment which wanted full access via NFSv4 or CIFs with the ability to modify permissions from either side it was horrible. In particular, in the mixed mode, it's a legacy application modified the UNIX mode bits rather than using ACLs, the ACL was completely wiped out. and while it was mapping available for users, there was no mapping of UNIX to Windows groups or vice versa. If you were in an environment that only accessed a particular set of files from one operating system, you were probably okay. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | [EMAIL PROTECTED] California State Polytechnic University | Pomona CA 91768 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS ACLs/Samba integration
On Thu, 13 Mar 2008, Richard Elling wrote: You can get support for SXDE. Perhaps you already have it. http://www.sun.com/service/subscriptions/sxde.xml We have a ton of hardware under Silver/Gold support, quite likely we might already qualify for this, although I was previously unaware of its existence. However, unless I misunderstood, support is only provided for the current release, and there are no patches available; you need to upgrade every three months or so... I don't think that will provide the stability management is requiring for our file system project. BTW, you don't happen to know any ACL experts you might be able to go nudge to take a look at my ACL question :)? -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | [EMAIL PROTECTED] California State Polytechnic University | Pomona CA 91768 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] ZFS ACLs/Samba integration
I'm currently prototyping a Solaris file server that will dish out user home directories and group project directories via NFSv4 and Samba. I have samba configured and integrated into our local active directory, with ACL mapping working. I'm a little confused as to the behavior of the ZFS ACL though. on a brand-new filesystem, touching a file results in: -rw-r--r-- 1 root csupomona 0 Mar 12 14:16 test owner@:--x---:--:deny owner@:rw-p---A-W-Co-:--:allow group@:-wxp--:--:deny group@:r-:--:allow everyone@:-wxp---A-W-Co-:--:deny everyone@:r-a-R-c--s:--:allow Why does ZFS include deny entries in the default ACL? Based on my understanding of ACL processing, the effective permissions would be exactly the same without them. It's particularly annoying when using Samba, as Windows expects all deny entries to be at the beginning of the list, and accessing the ACL from Windows results in a warning message and reordering of the ACL. I tried explicitly changing the ACL to something simpler: -rw-r--r-- 1 root csupomona 0 Mar 12 14:16 test owner@:rw-p---A-W-Co-:--:allow group@:r-:--:allow everyone@:r-a-R-c--s:--:allow This has the exact same effective permissions, but is easier on the eyes and to visually parse, plus interacts with Windows better. However, any interaction with the mode bits (for example, chmod g+w) results in a much more complicated ACL again including unnecessary deny components: -rw-rw-r--+ 1 root csupomona 0 Mar 12 14:16 test owner@:---A-W-Co-:--:allow group@:--:--:allow everyone@:--a-R-c--s:--:allow owner@:--x---:--:deny owner@:rw-p---A-W-Co-:--:allow group@:--x---:--:deny group@:rw-p--:--:allow everyone@:-wxp---A-W-Co-:--:deny everyone@:r-a-R-c--s:--:allow The ACL now has three entries each for owner, group, and everyone. My original simple ACL has been turned into something unnecessarily complicated, and no longer meeting the standard for a Windows ACL. I tried setting aclmode to passthrough in the hopes that would prevent ACL munging, but no such luck. I also experimented with configuring an initial ACL on the home directory with defined inherited permissions for new files and subdirectories: owner@:rwxp---A-W-C--:-d:allow owner@:rw-p---A-W-C--:f-i---:allow group@:--x---:-d:allow group@:--:f-i---:allow everyone@:--x---:-d:allow everyone@:--:f-i---:allow Intuitively, I would have expected a new file created in this directory to have permissions such as: owner@:rw-p---A-W-C--:--:allow group@:--:--:allow everyone@:--:--:allow Instead, a new file showed up as: owner@:---A-W:--:allow group@:--:--:allow everyone@:--:--:allow owner@:--x---:--:deny owner@:rw-p---A-W-Co-:--:allow group@:-wxp--:--:deny group@:r-:--:allow everyone@:-wxp---A-W-Co-:--:deny everyone@:r-a-R-c--s:--:allow Again, a much more complicated ACL than necessary, including unwanted deny entries, and group/other readability. I think the readability came from the umask of 022, but given explicitly defined inherited ACLs I don't think umask should have even been consulted. Again based on my explicitly configured inheritable ACL, I would have expected a new directory to look like: owner@:rwxp---A-W-C--:-d:allow owner@:rw-p---A-W-C--:f-i---:allow group@:--x---:-d:allow group@:--:f-i---:allow everyone@:--x---:-d:allow everyone@:--:f-i---:allow Instead I got: owner@:rwxp---A-W-C--:-di---:allow owner@:---A-W:--:allow owner@:rw-p---A-W:f-i---:allow group@:--x---:-di---:allow group@:--:--:allow group@:--:f-i---:allow everyone@:--x---:-di---:allow everyone@:--:--:allow everyone@:--:f-i---:allow owner@:--:--:deny owner@:rwxp---A-W-Co-:--:allow group@:-w-p--:--:deny group@:r-x---:--:allow everyone@:-w-p---A-W-Co-:--:deny everyone@:r-x---a-R-c--s:--:allow I'm not even sure what to make of this. It looks like the directory inheritable
Re: [zfs-discuss] ZFS ACLs/Samba integration
Paul B. Henson wrote: I'm currently prototyping a Solaris file server that will dish out user home directories and group project directories via NFSv4 and Samba. I have samba configured and integrated into our local active directory, with ACL mapping working. I'm a little confused as to the behavior of the ZFS ACL though. Your options are probably going to come down to losing (detailed) ACLs, picking a protocol, or picking a platform (and therefore, a protocol). CIFS ACLs and NFS ACLs are not on a convergence course, are they? Maybe a NetApp could do some kind of mapping to satisfy your idea, but of even that I'd be skeptical. Roy ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS ACLs/Samba integration
On Wed, 12 Mar 2008, Roy Butler wrote: CIFS ACLs and NFS ACLs are not on a convergence course, are they? Maybe NFSv4 ACLs (the ZFS native ACL) are based on CIFS/NT ACLs and virtually identical. The Sun version of Samba does just about a perfect mapping between them. a NetApp could do some kind of mapping to satisfy your idea, but of even that I'd be skeptical. We eval'd a netapp box. ACL mapping on netapp sucks. You really need to either use unix or windows privs, not both. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | [EMAIL PROTECTED] California State Polytechnic University | Pomona CA 91768 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
