wjw@eba.eb.ele.tue.nl (Willem Jan Withagen) (10/04/90)
Hi ya'll I know that it's not nice to keep hammering (or would the word be bashing) Apollo, BUT! 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!!) Is there anything that can be done about this? (I mean the priority problem, not about the HP-response. :-) ) 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. Thanx, Willem Jan. Eindhoven University of Technology DomainName: wjw@eb.ele.tue.nl Digital Systems Group, Room EH 10.10 BITNET: ELEBWJ@HEITUE5.BITNET P.O. 513 Tel: +31-40-473401 5600 MB Eindhoven The Netherlands
awhitton@bwdla30.bnr.ca (Alan Whitton @ BNR) (10/05/90)
In article <836@eba.eb.ele.tue.nl>, wjw@eba.eb.ele.tue.nl (Willem Jan Withagen) writes: |> Hi ya'll |> |> I know that it's not nice to keep hammering (or would the word be bashing) |> Apollo, BUT! |> |> 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. Well we found this one out after we found that the RGYD process which usually hogs CPUs suddenly being niced way down. The fix that the hot line gave me was "... simply change the ACLs so only root can execute it...", JEEZ! An APR has been submitted on this APR DC94E (although I don't know what it is now in the HP world...). Cheers, Alan Whitton -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- BNR Ottawa Disclaimer: "This is only my opinion" BITNET: awhitton@bnr.ca OR UUCP: ...uunet!bnrgate!forum!awhitton
system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) (10/06/90)
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
chen@digital.sps.mot.com (Jinfu Chen) (10/08/90)
In article <1990Oct5.170012.13818@alchemy.chem.utoronto.ca> system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) writes: >"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. You may even shock if you're running pre-SR10.2, anyone can sigp (kill) any process not own by the user.
tim@apollo.HP.COM (Timothy R. Giebelhaus) (10/09/90)
In article <4d46b8d1.12c9a@digital.sps.mot.com> chen@digital.sps.mot.com (Jinfu Chen) writes: >You may even shock if you're running pre-SR10.2, anyone can sigp (kill) any >process not own by the user. This transcript is from running bsd. Yes, one can change priority, but by changing the rights on the node owners file, one can control who can kill processes: stubai% renice 20 -p 6699 6699: old priority 0, new priority 20 stubai% kill -TERM 6699 6699: Not owner stubai% ps guaxN | grep xload | grep user uid = 4d4bc4a4.60018998 user 6699 1376 290 ? S N 0:02 xload stubai% sigp -s -u 4d4bc4a4.60018998 ?(sigp) Unable to signal "uid_process" - permission denied (OS/level 2 process manager) stubai% lsacl /sys/node_data/node_owners Object ACL: root.%.% prwx- %.staff.% [Ignore] %.%.none [Ignore] %.%.% ----k Extended entry mask: ----- stubai% UUCP: uunet!hi-csc!apcimsp!tim ARPA: tim@apollo.com Contents of this message has nothing to do with work.