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 components got inherited both as effective permissions with the
inherit flag intact, along with an additional copy of the exact same
permissions without the flag? And more unnecessary deny entries :(.
I had very high hopes for ACLs under ZFS; the inclusion of the NFSv4 ACL as
the native filesystem ACL seemed like it would be perfect for sharing
between Unix system and Windows systems.
Unfortunately, from initial review it looks like the ACL situation is much
more complicated than I would have liked.
Is there anyway to get ZFS to not overly complicate the ACLs?
On another note, a question regarding the attributes aclinherit and
aclmode. It seems in an environment with explicitly defined ACLs, the best
setting for those would be passthrough. I''m not sure why you would want
explicitly defined ACLs to be munged?
In particular, consider the example of a project directory where the
project administration group should have full control over all files
created in that directory regardless of owner (including the ACL). With the
default "secure" setting, this is not achievable.
For the aclmode setting, the default groupmask seems intended to to emulate
the behavior of the POSIX mask_obj. I always hated that, I would have hoped
ZFS as a brand-new filesystem with native ACLs from the beginning would
have taken the opportunity not to include such kludges, or at least not
make them the default.
I am inclined to configure both of these settings to be passthrough. Is
there any scenario I am not thinking of (particularly given one of them is
called "secure"; which gives one a feeling that changing it would be
"insecure") that would make such a setting problematic?
Thanks for any commentary...
--
Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst | henson at csupomona.edu
California State Polytechnic University | Pomona CA 91768
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
On Wed, 12 Mar 2008, Roy Butler wrote:> CIFS ACLs and NFS ACLs are not on a convergence course, are they? MaybeNFSv4 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 | henson at csupomona.edu California State Polytechnic University | Pomona CA 91768
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
> 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
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.
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
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 | henson at csupomona.edu California State Polytechnic University | Pomona CA 91768
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
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 | henson at csupomona.edu California State Polytechnic University | Pomona CA 91768
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.xmlWe 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 | henson at csupomona.edu California State Polytechnic University | Pomona CA 91768
On Thu, Mar 13, 2008 at 11:33:57AM +0000, 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
Jens Elkner wrote:> On Thu, Mar 13, 2008 at 11:33:57AM +0000, 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:marks at CIFSDEVDC unixuser:marks # ls -V New* -rw-rw----+ 1 marks 2147483650 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
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 | henson at csupomona.edu California State Polytechnic University | Pomona CA 91768
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 sys 2 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 this? There are three unnecessary deny entries, the group did not > get write ability, and everyone has readability even though that was not > intended. I see this behavior even after changing aclinherit to > passthrough. > > My umask was 022 for the previous test, I changed it to 000 for this: > > -rw-rw-rw-+ 1 root root 0 Mar 14 14:53 groupw/file2 > everyone@:--------------:------:allow > group@:--------------:------:allow > owner@:--------------:------:allow > owner@:--x-----------:------:deny > owner@:rw-p---A-W-Co-:------:allow > group@:--x-----------:------:deny > group@:rw-p----------:------:allow > everyone@:--x----A-W-Co-:------:deny > everyone@:rw-p--a-R-c--s:------:allow > > Now, group does have write permissions as was intended, but so does > everyone. > > Restoring my umask, I created a directory: > > drwxrwxr-x+ 2 root root 2 Mar 14 14:55 groupw/dir > everyone@:--------------:f-i---:allow > group@:rw------------:f-i---:allow > owner@:rw------------:f-i---:allow > owner@:rwxp---A-W-Co-:-di---:allow > owner@:-------A-W----:------:allow > group@:rwxp----------:-di---:allow > group@:--------------:------:allow > everyone@:--------------:-di---:allow > everyone@:--------------:------: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 > > > 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.> > On the other hand, let''s say I wanted to create a directory which would > have no privileges available to the group for new stuff inside of it: > > > drwx------+ 2 root root 2 Mar 14 14:46 groupnw > everyone@:--------------:f-i---:allow > group@:--------------:f-i---:allow > owner@:rw------------:f-i---:allow > owner@:rwxp---A-W-Co-:-d----:allow > group@:--------------:-d----:allow > everyone@:--------------:-d----:allow > > A new file with default umask 022: > > > -rw-r--r--+ 1 root root 0 Mar 14 14:54 groupnw/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 > > Group and everyone readability that was not wanted. > > And with umask 000: > > -rw-rw-rw-+ 1 root root 0 Mar 14 14:55 groupnw/file2 > everyone@:--------------:------:allow > group@:--------------:------:allow > owner@:--------------:------:allow > owner@:--x-----------:------:deny > owner@:rw-p---A-W-Co-:------:allow > group@:--x-----------:------:deny > group@:rw-p----------:------:allow > everyone@:--x----A-W-Co-:------:deny > everyone@:rw-p--a-R-c--s:------:allow > > Group and everyone readability and writability. > > 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.> To achieve directories in which files are created with my desired > permissions, it seems I would need to construct a horribly complicated ACL > with a bunch of deny''s to override the automatically created allows? > > I am very sad; we have been searching for ages for a filesystem to deploy > that would allow simultaneous access via NFSv4 and CIFS, with equivalent > permissions from both sides, equivalent access from both sides, and the > ability to change permissions are either side and have them make sense on > the other. I thought ZFS with NFSv4 native ACL support was going to it -- > but so far the ACL implementation makes no sense to me. > >
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 | henson at csupomona.edu California State Polytechnic University | Pomona CA 91768
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 everyone at . 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... > >
On Fri, 14 Mar 2008, Mark Shellenbaum wrote:> 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.Considering how long ZFS has been out, if no one has complained about it before, it''s most likely that (as is often the case) my requirements are out of the ordinary <sigh>. Even if an RFE were accepted and implemented, it would presumably be years before it showed up in a production Solaris release, which wouldn''t meet the implementation timeline for the project in question. Thanks for the feedback; at least now I better understand why ZFS ACLs are broken for my needs. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | henson at csupomona.edu California State Polytechnic University | Pomona CA 91768
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
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 | henson at csupomona.edu California State Polytechnic University | Pomona CA 91768
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
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 | henson at csupomona.edu California State Polytechnic University | Pomona CA 91768
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
Reasonably Related Threads
- enterprise scale redundant Solaris 10/ZFS server providing NFSv4/CIFS
- msdfs root -- client error "refers to a location that is unavailable"
- dovecot2 auth-worker socket perms ignoring assigned ownership settings in conf.d/10-master.conf?
- mysql auth failover failing
- Kerberos/GSSAPI support