Greetings, (a)The way I am reading the function header: upon failure *working_mode is supposed to contain all the permission bits we asked for, but did not get for whatever reason. (b)The way it is implemented, it returns any access bits we asked for, but we did not get because it was explicitly denied via a "deny" acl. Assume we ask for read-write on a file and have a single acl that permits read, but not write. The call fails overall, but returns 0 in work_mode (because there was no deny acl present at all). I fail to see why this makes sense. Behavior (a) would, IMO. Comments? Steve -- This message posted from opensolaris.org
Mark Shellenbaum
2009-Nov-30 22:47 UTC
[zfs-code] zfs_zaccess_aces_check working_mode return
Steve Gonczi wrote:> Greetings, > > (a)The way I am reading the function header: upon failure *working_mode is supposed to contain all the permission bits > we asked for, but did not get for whatever reason. > > (b)The way it is implemented, it returns any access bits we asked for, but we did not get because it was > explicitly denied via a "deny" acl.denied or not explicitly allowed.> > Assume we ask for read-write on a file and have a single acl that permits read, but not write. The call fails overall, > but returns 0 in work_mode (because there was no deny acl present at all).It should return with ACE_WRITE_DATA in working_mode> > I fail to see why this makes sense. Behavior (a) would, IMO. Comments? >As aces with the requested permissions are found they are removed from the working mode so we don''t check them again. With NFSv4 once an ACE has been denied or granted a subsequent ACE can''t take it away. If it was denied we need to remember that so that we can place it back on the working mode when we are all done. Only if a bit has been explicitly allowed will it be removed from the working_mode when the function exits. This information is then later used to determine what privileges are needed to grant access when the ACL itself doesn''t grant all that was requested. -Mark