On 10/30/06, Darren J Moffat <Darren.Moffat at sun.com> wrote: > James Carlson wrote: > Why, other than the returning an error we already have 5 such privileges > in the basic set. Now in each of those cases (proc_info, proc_session, > proc_fork, proc_exec, file_link_any) there is a way to return an error > for sync(2) but there is for 'lockfs -f'.
I assume the above was supposed to be "there is no way to return an error for sync(2)..." It seems as though the key interest in non-root users being able to run sync(1m) is in reaction to some perceived doom on its way (thunder that comes a few seconds after the lightning, etc.). If sync(2) were change to check for a privilege (PRIV_SYS_SYNC?) before calling vfs sync(), it indeed would not return an error. However, sync(1m) could do the same check that sync(2) does and return the appropriate error. 'lockfs -f' seems as though it would be able to get an error from ufs_fioffs(). > > For the zones case maybe it can not be in the default set of privileges > given to a zone, so by default they get to run more quickly. Just like > with many other privileges the admin can choose the limitset of > privileges the zone has. True enough. Does it make sense to progress with this as: 1) Create a new privilege PRIV_SYS_SYNC 2) Alter sync(2) or vfs_sync() to only perform the sync if the calling process has PRIV_SYS_SYNC. 3) Alter ufs_fioffs() to only perform the sync if the calling process has PRIV_SYS_SYNC. On failure return EPERM. 4) Alter sync(1m) to check for PRIV_SYS_SYNC and say "Permission Denied" and exit with a non-zero value if the permission is not held. 5) Alter rc0.sh to only call sync(1M) if running in the global zone. 6) Alter svc.startd(1M) to only call sync(2) if running in the global zone. Assuming we do steps 1 and 2 above, do we get into any problems with POSIX compliance if the default basic privilege set does not include PRIV_SYS_SYNC? Mike -- Mike Gerdts http://mgerdts.blogspot.com/