destroy does...!

[newdep]

Hi Lutz,



I thought I found a flaw (while being not root)

and im still looking into it => but meanwhile..



Perhpas this can be protected?

Wrong use of (destroy) reboots a machine instantly.

Now normaly you dont run as root, but you cant see

it from the newlisp prompt if you are root or not,

and I normaly dont  check it eighter.. Here is the case =>



(destroy 0) kills current newlisp progress on UNIX, on windows it returns nil.



(destroy -1) kills current newlisp proces on Windows

on unix it kills your login or X sessions instantly when you are not root.

When you are root it kill your machine instantly !

(thats correct because "kill -9 0" does the same on unix)





So actualy is this a Flaw? Yes and no..

On Operating Level this is not a bug, but because you

use newlisp as a programmer and not as an System operator

its more of a flaw...





The PID "-1" is not documented under Unix (or somewhere hard to find),

although its perhpas logical to use "-1" for the process that

started your process its does not explicitly notify you on

anything...It just Kills instantly.





For security reasons (user protection) I would like to advice to

block all PID killing lower than 0 inside newlisp while using (destroy).

( or document the behaviour of destroy with a risk-mark..)







My oneliner for to day; "Hope its worth looking into, C adjustment is a one liner.. ;-)"





PS: I did not test it on OpenBsd but i will tonight..



PPS: just tested it, OBsd does the same kills root PID with -1 as user

but as Root is does not shutdown the machine! (Long live Obsd , Again!)





Norman.

[Lutz]

Destroy is implemented using the system call kill() (not the UNIX utility, but the libc function).



Using 0 and especially -1 as a PID have a dramatic effect. This is what the BSD man page says to this topic:



If pid is greater than zero:

  Sig is sent to the process whose ID is equal to pid.



If pid is zero:

  Sig is sent to all processes whose group ID is equal to the process group ID

  of the sender, and for which the process has permission; this is a variant of

  killpg(2).



If pid is -1:

  If the user has super-user privileges, the signal is sent to all processes

  excluding system processes and the process sending the signal.  If the user

  is not the super user, the signal is sent to all processes with the same uid

  as the user, excluding the process sending the signal.  No error is returned

  if any process could be signaled.





on Mac OS X -1 kills all user processes, but will not reboot and shouldn't on a correctly configured OS when running newLISP under normal user permissions. Still, I agree that -1 is kind of dramatic: killing all processes owned started by the user. On Mac OS X the screen goes blue for a second, but then comes back without a reboot.



That power could be a good thing: using 'exec' and 'process' newLISP can do all kinds of dangerous stuff and (destroy -1) could be a good emergency break in some situations, bringing down everything in a fraction of a second.



A decision on this is not easy. My first reaction would be, don't take away what the OS clearly is giving you. Of course this would have to be documented for newLISP 'destroy' too. On the other side, I agree that its doing more then most programmers would expect :-). I wonder what others have to comment on this topic. Should we supress -1 ?

[newdep]

Personaly i now know it works ;-) (by accident today! btw..)

(Lost a solaris machine today and took me 2 hours to repair 4 disks)



I would then suggest to point this issue in the manual as

dangerous using those pids being root (in this case its god-mode ;-)



Btw.. Bsd protects its nicley indeed, my OpenBsd doesn't

allow a reboot this way. (thats i.e. why I like Bsd better then linux

Not to speak about Solaris..because i dont like that at all... I

did not test Tru64 btw.. perhpas pjot can test that I dont have a

Tru64 at hand now..(he took them all) ;-)