Nicolai Johannes wrote:
Thank you for your hints.
I already investigated the zfs/ufs/tmpfs code when I wrote my proposal.
When I wrote check if set, I mean doing this with new secpolicy_vnode_*
functions. The check for the already existing privileges would of course stay
in secpolicy_vnode_owner and secpolicy_vnode_access.
The proposed checking order is of course only relevant for permission checks.
For changing permissions, I think, the new checking order is rather clear and
was not explicitely mentioned:
Just so I am understanding this correctly. All of the PRIV_IDENTITY_*
privs look only at euid or egid?
Are the below steps for doing a chmod(2)?
1. Check whether process is owner of the file, if not go to step 3, else
proceed with step 2.
2. Check whether PRIV_FILE_IDENTITY_OWNER as well as all PRIV_FILE_IDENTITY_*
privileges that correspond with the new permissions are set. If so, change
permissions and return success, else go to step 3.
3. Check whether PRIV_FILE_OWNER is set, if so change permissions and return
success, else determine whether we come from step 1 or two and report mssing
ownership or missing priviileges to the user.
You can't break the access control rules for ZFS that are enforced by
the NFSv4 spec. Typically an ACL for ZFS will be laid out so that the
owner will be checked first, but a user could reconstruct an ACL so that
isn't true. For UFS the owner will always be checked for first.
The rules pretty much have to be:
1. file system checks to see if access should be granted, based on
permission bits or file ACL. When a file has an ACL it could be either
an additional access control method or an alternate in POSIX
terminology. It depends on the file system which it is.
2. If access can't be granted then the file system asks the priv code if
it wishes to override denying access.
The other owner related checks should be similar.
Imagine the situation, when a procss would be able to open a file because it is
the owner of the file and the permission bits for the owner grant access. The
unmodified code would allow the access, because it won't even call the
secpolicy functions.
So unfortunately, to my mind, I have to change the file system code and cannot
incorporate my privilege checking into the existing sec_policy functions, 8-(
If the permission bits or ACL of a file specify that it should be
allowed to open a file, then the process should be allowed to open the file.
I thought that privileges only granted additional access that would
otherwise be denied by a file's permission bits/ACL. This sounds like
you want the presence of certain privileges to override permission bits?
-Mark
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
