Mike Gerdts wrote:
> 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)..."

Yes I did.

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

What check ?  Only the kernel (and the Xserver when TX is running)
checks privileges, applications should never check privileges and make
assumptions based on them.

> 'lockfs -f' seems as though it would be able to get an error from 
> ufs_fioffs().

Yes or from the equivalent for other filesystems that implement
that ioctl as well.

> Does it make sense to progress with this as:
> 1) Create a new privilege PRIV_SYS_SYNC

Seems as reasonable a name as any.

> 2) Alter sync(2) or vfs_sync() to only perform the sync if the calling
> process has PRIV_SYS_SYNC.

Either is probably fine.

> 3) Alter ufs_fioffs() to only perform the sync if the calling process
> has PRIV_SYS_SYNC.  On failure return EPERM.

Yes and check ZFS and the other filesystems too.

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

No applications should not check privileges, though in this case
it might be okay since you know you need sys_sync to call sync(2)
and if you don't have it what is the point.  In the general case
though one is supposed to try the operation rather than assume
based on the privileges one has.

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

I'll leave those to a zones expert to answer.

> 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

As soon as you manipulate the privilege sets you are already operating
outside of POSIX so it doesn't apply.

Darren J Moffat

Reply via email to