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:
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. 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-( Please tell me if I am wrong. Thank you Johannes -----Ursprüngliche Nachricht----- Von: Mark Shellenbaum [mailto:[EMAIL PROTECTED] Gesendet: Mi 21.06.2006 18:11 An: Nicolai Johannes Cc: zfs-discuss@opensolaris.org; [EMAIL PROTECTED] Betreff: Re: [zfs-discuss] Proposal for new basic privileges related with filesystem access checks Nicolai Johannes wrote: > For my Google Summer of Code project for OpenSolaris, my job is to think > about new basic privileges. I like to propose five new basic privileges that > relate with file system access checks and may be used for daemons like ssh or > ssh-agent that (after starting up) never read or write user specific files: > > PRIV_FILE_IDENTITY_READ: > Allow the process to benefit from its supplemental rights associated with its > identity (euid, egid and associated groups) during file or directory > operations that require read permissions. Additional rights gained through > PRIV_FILE_DAC_READ will not be affected. > > PRIV_FILE_IDENTITY_WRITE: > Allow the process to benefit from its supplemental rights associated with its > identity (euid, egid and associated groups) during file or directory > operations that require write permissions. or ownership of the file. > Additional rights gained through PRIV_FILE_DAC_WRITE, PRIV_FILE_OWNER and > PRIV_FILE_SETID will not be affected. > > PRIV_FILE_IDENTITY_OWNER: > Allow the process to benefit from its supplemental rights associated with its > identity (euid, egid and associated groups) during file or directory > operations that require ownership of the file if PRIV_FILE_IDENTITY_READ and > PRIV_FILE_IDENTITY_WRITE are set as well. If PRIV_FILE_IDENTITY_READ and > PRIV_FILE_IDENTITY_WRITE are not both present, PRIV_FILE_IDENTITY_OWNER will > not grant any supplemental rights. > Additional rights gained through PRIV_FILE_OWNER and PRIV_FILE_SETID will not > be affected. > > PRIV_FILE_IDENTITY_SEARCH: > Allow the process to benefit from its supplemental rights associated with its > identity (euid, egid and associated groups) during directory operations that > require search permissions. Additional rights gained through > PRIV_FILE_DAC_SEARCH will not be affected. > > PRIV_FILE_IDENTITY_EXECUTE: > Allow the process to benefit from its supplemental rights associated with its > identity (euid, egid and associated groups) during directory operations that > require execute permissions. Additional rights gained through > PRIV_FILE_DAC_EXECUTE will not be affected. > > > If this seems to be too much new privileges, one could merge > PRIV_FILE_IDENTITY_EXECUTE, PRIV_FILE_IDENTIY_SEARCH and > PRIV_FILE_IDENTITY_READ as well as PRIV_FILE_IDENTITY_OWNER and > PRIV_FILE_IDENTITY_WRITE together. > > So dropping the privileges is almost the same as if the process is running > under an uid/egid that does not own any file or have permissions for any > file. Only almost the same because dropping the privileges won't allow to > access files that have permissions associated with them that deny access with > the egid/euid. > > The new privileges willl at least affect open, creat, link, unlink, stat, > exec, chmod, chgrp, chown, acl_set, acl_get and opendir. > > With dropping PRIV_FILE_ALLOW_IDENTITY_OWNER (and having no privilegs like > PRIV_FILE_OWNER/SETID), the process won't be able to create files/directories > (every file/directory needs to have an owner and its initial permissions may > be manipulated), change permissions or owner/group. But it will still be > possible to delete files/directories if everyone may delete this file (and > the process would be able to if the new privileges were set). > > My mentor, Darren Moffat, suggested that I should start integrating the new > privileges checks in ZFS, UFS and TMPFS (in this order) and then proceed with > the various other file systems. > I am relatively certain that I will find the appropriate places in the ZFS > code due to the fact that the checks will correlate with the already present > checks of the established PRIV_FILE_* privileges. > More worries, I have with the checking order. I suggest three possibilities > here: > You might want to consider a different implementation order. I would recommend TMPFS, UFS and then ZFS. The reason for this is TMPFS only has permission bits and UFS has a simpler ACL model than ZFS. Standard file access for ufs/zfs/tmpfs does basically the following: 1. check requested access mode against files permission bits/acl. 2. If access is NOT granted from step 1, then secpolicy_vnode_access() is called which will then determine if process has necessary privileges to grant the request. 3. Solaris file systems never check explicitly for PRIV_XXX_XXXX privileges. Instead it relies on secpolicy_XXX() functions to handle those decisions. If you are able to implement the new priv checking in the already used secpolicy functions, then hopefully you shouldn't need to modify any file system code. Access checking for chown/chgrp/utime/... aka VOP_SETATTR() goes through a different flavor of secpolicy functions. -Mark _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
