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