Path: utzoo!attcan!uunet!zephyr.ens.tek.com!uw-beaver!ubc-cs!news-server.csri.toronto.edu!helios.physics.utoronto.ca!alchemy.chem.utoronto.ca!system
From: system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson))
Newsgroups: comp.sys.apollo
Subject: Re: Renice and ppri, only for those that are authorised??
Message-ID: <1990Oct5.170012.13818@alchemy.chem.utoronto.ca>
Date: 5 Oct 90 17:00:12 GMT
References: <836@eba.eb.ele.tue.nl>
Organization: University of Toronto Chemistry Department
Lines: 48

In article <836@eba.eb.ele.tue.nl> wjw@eba.eb.ele.tue.nl (Willem Jan Withagen) writes:
>Did anybody read the manual page for /etc/renice. Well it states that
>a normal user can only change it's 'own' priorities, and the SuperUser
>can change any. 
>As to be expect: It is not true.
>
>Now this I don't really consider something to get mad about.
>What I do get mad about is that the manual page is just one plain lye.
>Anybody can change anybodies priorities with /etc/renice.
>Now this could also be done with ppri and here the manual does not mention
>any restriction. So it's not all that smart to restict one program, and
>have another around which does the job without restriction.
>
>I expect this to fall into the catagory of "features like by some of our
>users" as mentioned in the HP-response to the open letter.
>(This letter was considered nothing but PR-humbug by a lot of people 
> I spoke!!)

"Isn't this a nice feature" was their response when I APR'ed this over a
year ago.  This "feature" is ridiculous - anyone can change the priority
of ANY process, either up or down.
Note also that renice priorities 2 through 20 inclusive are in fact all
the same Domain/OS priority, negating most
attempts to run background jobs deep in the background.
 
>Is there anything that can be done about this? (I mean the priority problem,
>not about the HP-response. :-) )

We will have to wait and see if anything happens re the letter - at the
ADUS conference in San Diego, it was discussed at some length, and
"action plans are being formulated".

The problem will not be fixed before SR11, and is only under consideration
even then (same with the mapping of priorities 2-20 to the same real
priority).
 
>Again this question could be seen in the view of asking Apollo to be more
>UniX. I don't see it this way. I would like Apollo's to be safe,
>(Given that this is only a minor quirk) and that would mean that things
>like ppri and renice have a restriction list. Instead of being wide open!
>I consider it even a better solution when only root ( and not the node_owner )
>could upgrade priorities, instead of everybody.

I completely agree.
-- 
Mike Peterson, System Administrator, U/Toronto Department of Chemistry
E-mail: system@alchemy.chem.utoronto.ca
Tel: (416) 978-7094                  Fax: (416) 978-8775