zfs discuss - Jul 2011 - revisiting aclmode options

Now that illumos has restored the aclmode option to zfs, I would like to 
revisit the topic of potentially expanding the suite of available modes. 
Some of you no doubt recall a fairly lengthy (and sometimes heated ;) ) 
discussion of this topic on the zfs-discuss mailing list a bit over a 
year ago, looks like a fairly comprehensive thread archive is available at:

http://opensolaris.org/jive/thread.jspa?messageID=463237&#463237

The final outcome at the time was decided solely by Sun/Oracle as the 
arbitrator of OpenSolaris, and their decision was to simply remove 
aclmode entirely. The basis for that decision was not necessarily 
technical merit, nor lack of a need for such a feature, but quite simply 
a business case analysis -- they felt it would cost them less to support 
an operating system without that particular tuning knob.

It''s obvious that decision didn''t agree with the community, as
evidenced
by the re-addition of the option in the open source illumos. I''m hoping
that the community might also be more willing to consider the technical 
merits of additional flexibility in the option and be more focused on 
providing functionality than on minimizing support costs :).

My basic premise is that there should be some way to effectively treat a 
zfs filesystem as ACL-only; while mode bits will most likely be needed 
for quite some time for backwards compatibility, they should be treated 
as a second-class citizen, reflecting as closely as possible the 
intention of the underlying ACL, but in a read-only fashion, with no way 
to destroy the underlying ACL by manipulating them.

I initially proposed two extensions to aclmode. First, "deny" -- any 
attempt to execute a chmod that would result in a change to the 
underlying ACL would fail with a permission denied error. Second, 
"discard" -- any attempt to execute a chmod that would result in a 
change to the underlying ACL, assuming it would otherwise succeed, would 
appear to suceed but not actually change the permissions.

Clearly, these types of modes could cause problems for certain 
scenarios. On the other hand, the existing modes also cause problems for 
certain scenarios. Ideally, an administrator would have the flexibility 
to choose which problems he prefers to deal with :). It would be really 
nice if the aclmode could be specified on a per object level rather than 
a per file system level, but that would be considerably more difficult 
to achieve 8-/.

If illumos would be willing to consider integrating a change like this, 
I would like to discuss the technical details and determine the best 
possible implementation.

Thanks...


-- 
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 Mon, Jul 18, 2011 at 06:44:25PM -0700, Paul B. Henson
wrote:
> It would be really  
> nice if the aclmode could be specified on a per object level rather than  
> a per file system level, but that would be considerably more difficult  
> to achieve 8-/.
If there were an acl permission for "set legacy permission bits",
as distinct from write_acl, that could be set to "deny" at whatever
granularity you needed...  

--
Dan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20110720/c6445056/attachment.bin>

On Mon, Jul 18, 2011 at 9:44 PM, Paul B. Henson <henson at acm.org>
wrote:
> Now that illumos has restored the aclmode option to zfs, I would like to
> revisit the topic of potentially expanding the suite of available modes.
[...]

At one point, I was experimenting with some code for smbfs that would
"invent" the mode bits (remember, smbfs does not get mode bits from
the remote server, only the ACL).  I ended up discarding it there due to
objections from reviewers, but the idea might be useful for people who
really don''t care about mode bits.  I''ll attempt a description
below.


The idea:  A new "aclmode" setting called "discard", meaning
that the
users don''t care at all about the traditional mode bits.  A dataset
with
aclmode=discard would have the chmod system call and NFS setattr
do absolutely nothing to the mode bits.  The getattr call would receive
mode bits derived from the ACL.  (this derivation would actually happen
when and acl is stored, not during getattr)  The mode bits would be
derived from the ACL such that the mode represents the greatest
possible access that might be allowed by the ACL, without any
consideration of deny entries or group memberships.

In detail, that mode derivation might be:

The mode''s "owner" part would be the union of access granted
by any
"owner" type ACEs in the ACL and any ACEs where the ACE owner
matches the file owner.  The mode''s "group" part would be the
union
of access granted by any group ACEs and any ACEs who''s type is
unknown (all SIDs are of unknown type).  The mode''s "other"
part
would be the access granted by an "Everyone" ACE, if present.

Would that be of any use?

Gordon

On 7/19/2011 6:37 PM, Daniel Carosone wrote:
> If there were an acl permission for "set legacy permission bits",
> as distinct from write_acl, that could be set to "deny" at
whatever
> granularity you needed...
That does sound interesting; but given it would most likely require an 
update to the NFS 4 ACL spec not very probable, particularly in the 
short term...

-- 
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 7/19/2011 7:10 PM, Gordon Ross wrote:
> The idea:  A new "aclmode" setting called "discard",
meaning that
> the users don''t care at all about the traditional mode bits.  A
> dataset with aclmode=discard would have the chmod system call and NFS
> setattr do absolutely nothing to the mode bits.
The caveat to that are the suid/sgid/sticky bits, which have no
corresponding bits in the ACL, and potentially will still need to be
manipulated. The details on that still need to be worked out :).
> The mode bits would be derived from the ACL such that the mode
> represents the greatest possible access that might be allowed by the
> ACL, without any consideration of deny entries or group memberships.
Is this description different than how the mode bits are currently 
derived when a ZFS acl is set on an object?

-- 
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, Jul 21, 2011 at 9:58 PM, Paul B. Henson <henson at acm.org>
wrote:
> On 7/19/2011 7:10 PM, Gordon Ross wrote:
>
>> The idea: ?A new "aclmode" setting called
"discard", meaning that
>> the users don''t care at all about the traditional mode bits.
?A
>> dataset with aclmode=discard would have the chmod system call and NFS
>> setattr do absolutely nothing to the mode bits.
>
> The caveat to that are the suid/sgid/sticky bits, which have no
> corresponding bits in the ACL, and potentially will still need to be
> manipulated. The details on that still need to be worked out :).
It seems consistent to me that a "discard" mode would simply
never present suid/sgid/sticky.  (It discards mode settings.)
After all, the suid/sgid/sticky bits don''t have any counterpart in
Windows security descriptors, and Windows ACL use interited
$CREATOR_OWNER ACEs to do the equivalent of the sticky bit.
>> The mode bits would be derived from the ACL such that the mode
>> represents the greatest possible access that might be allowed by the
>> ACL, without any consideration of deny entries or group memberships.
>
> Is this description different than how the mode bits are currently derived
> when a ZFS acl is set on an object?
I think it''s pretty much the same, though I haven''t looked
recently
at the code that derives the mode from an  ACL.

Gordon

On 8/2/2011 7:07 AM, Gordon Ross wrote:
> It seems consistent to me that a "discard" mode would simply
never
> present suid/sgid/sticky.  (It discards mode settings.) After all,
> the suid/sgid/sticky bits don''t have any counterpart in Windows
> security descriptors, and Windows ACL use interited $CREATOR_OWNER
> ACEs to do the equivalent of the sticky bit.
I see it somewhat differently; the purpose of "discard" is to prevent
any attempted change of the mode bits via chmod from affecting the ACL.
As you point out, there is no corresponding functionality in NFSv4 ACLs,
so by definition a change of the suid/sgid/sticky part of the mode bits
would not affect the ACL. And not allowing them to be changed would
result in lost functionality -- for example, setting the sgid bit on the
directory so the group owner is inherited on child directories, which is
actually quite valuable for the functionality of the group@ entry.

So I think the implementation of both a "discard" and "deny"
aclmode
would need to incorporate the ability to modify the parts of the mode
bits that are not related to the ACL.


-- 
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