James Carlson wrote:
> Darren J Moffat writes:
>> Dan Price wrote:
>>> I know that at some point the performance guys wanted to make sync's by
>>> non-root users do nothing, but IIRC it was deemed too risky or something.
>>> Maybe we should go do that for Nevada.  Anyone in request-sponsor land
>>> have some background info they could point us at?
> [...]
>> I think these might be ideally specified as basic privileges, that is 
>> all users have them by default (just like the ability to see the 
>> existence of others processes in ps output) but they can be removed by 
>> the system admin.
> I think it'd be a little odd to have a privilege that works like
> this.  The implication seems to be that if you have the privilege,
> then sync does what it's always done.  If you don't, then sync
> silently does nothing at all.  (I don't see any clear way for sync(2)
> to return a failure ...)

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

> For zones, why would I want to choose between allowing zones to
> operate more quickly (by removing this privilege) and allowing zone
> users to save their work during thunderstorms?  I'm not sure I know
> how a customer should make such a decision.

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.

Darren J Moffat

Reply via email to