Hi,
	I was wondering, what are all the issues a hacker would have to hack my
computer if he gave me a few files.gif, file.pov and file.ini to render?

I know in the file.ini there are (from man povray)
       Pre_Scene_Return=return action
       Pre_Frame_Return=return action
       Post_Scene_Return=return action
       Post_Frame_Return=return action
      User_Abort_Return=return action
       Fatal_Error_Return=return action

is there such thing in a file.pov? or is there something else in the file.ini???

This information is Very important to me!


-- 
+-------------------------+----------------------------------+
| Simon Lemieux           | Website : http://www.666Mhz.net  |
| Email : Sin### [at] 666Mhznet | POV-Ray, OpenGL, C++ and more... |
+-------------------------+----------------------------------+

Post a reply to this message

It is possible to open a file for writing (and then write something in
there) within the .pov file.
  This can be used to write (or overwrite) system files, configuration
files, login files and so on.
  For example, if you are using dos/windows povray, the .pov file, when
povray is parsing it, could open your autoexec.bat and put some nasty
commands at the end of it (such as deltree...). In unix accounts it can
write nasty commands to your .login file and other similar user files (if
you are running povray with your own account privileges).

  Note also that the .ini file could specify an important system/user file as
the output image file for povray (that is, povray would overwrite the file
when writing the image). This can be quite dangerous specially in dos/windows.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

>   It is possible to open a file for writing (and then write something in
> there) within the .pov file.
>   This can be used to write (or overwrite) system files, configuration
> files, login files and so on.
>   For example, if you are using dos/windows povray, the .pov file, when
> povray is parsing it, could open your autoexec.bat and put some nasty
> commands at the end of it (such as deltree...). In unix accounts it can
> write nasty commands to your .login file and other similar user files (if
> you are running povray with your own account privileges).
> 
>   Note also that the .ini file could specify an important system/user file as
> the output image file for povray (that is, povray would overwrite the file
> when writing the image). This can be quite dangerous specially in dos/windows.

Interesting... that's exactly what I was looking for... do you know how it is
done?  So I can know how to avoid it?


-- 
+-------------------------+----------------------------------+
| Simon Lemieux           | Website : http://www.666Mhz.net  |
| Email : Sin### [at] 666Mhznet | POV-Ray, OpenGL, C++ and more... |
+-------------------------+----------------------------------+

Post a reply to this message

On Thu, 16 Nov 2000 15:10:09 -0500, Simon Lemieux wrote:
>Interesting... that's exactly what I was looking for... do you know how it is
>done?  So I can know how to avoid it?

You don't have to know how it's done to avoid it. :)

Your best bet is to run povray as a user with privileges only to write in 
a specific directory and no login privileges.  For extra security, you
might also use chroot.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Simon Lemieux wrote:
> 
> Hi,
>         I was wondering, what are all the issues a hacker would have to hack my
> computer if he gave me a few files.gif, file.pov and file.ini to render?
> 
> I know in the file.ini there are (from man povray)
>        Pre_Scene_Return=return action
>        Pre_Frame_Return=return action
>        Post_Scene_Return=return action
>        Post_Frame_Return=return action
>       User_Abort_Return=return action
>        Fatal_Error_Return=return action
> 
> is there such thing in a file.pov? or is there something else in the file.ini???

There has been quite a long thread about this issues a few months
(weeks) ago. Warp and Ron gave good ideas.
IMHO memory and disk consumption are issues.
If you make a scene featuring an infinite loop adding objects to an
union, you will have POV crash after running out of memory.
Unfortunately it is likely that some other processes die to, including
system services.
If you open a file and write to it in an infinite loop, you can fill
your disk completly, which can be harmful in some cases (under Un*x,
filling /tmp or /var can have odd consequences). Even if you suppress
user I/O, one can still decide to render a nearly empty scene (for
speed) at a huge resolution: 65536*65536*24bpp takes 1.5 Gb...

For these reasons I would suggest you use process limitations, such as
ulimit and quotas under Un*x.

-- 
François DISPOT  --  http://www.wozzeck.net
      __  __ __  __  _
|  | /  \  /  / |_  /  |/
\/\/ \__/ /_ /_ |__ \_ |\

Post a reply to this message

> You don't have to know how it's done to avoid it. :)

And what if... I want to know... if there are security problems in povray, I
need to know them...  You might have seen on povray.general that I've started
working on an utility for povray... well, that's why I would need these security
informations.

> Your best bet is to run povray as a user with privileges only to write in
> a specific directory and no login privileges.  For extra security, you
> might also use chroot.

What if I'm not on linux but on Windows? what about MacOS? what about the newer
MacOS X?

Thanks,
	Simon

-- 
+-------------------------+----------------------------------+
| Simon Lemieux           | Website : http://www.666Mhz.net  |
| Email : Sin### [at] 666Mhznet | POV-Ray, OpenGL, C++ and more... |
+-------------------------+----------------------------------+

Post a reply to this message

> There has been quite a long thread about this issues a few months
> (weeks) ago. Warp and Ron gave good ideas.
> IMHO memory and disk consumption are issues.
> If you make a scene featuring an infinite loop adding objects to an
> union, you will have POV crash after running out of memory.
> Unfortunately it is likely that some other processes die to, including
> system services.
> If you open a file and write to it in an infinite loop, you can fill
> your disk completly, which can be harmful in some cases (under Un*x,
> filling /tmp or /var can have odd consequences). Even if you suppress
> user I/O, one can still decide to render a nearly empty scene (for
> speed) at a huge resolution: 65536*65536*24bpp takes 1.5 Gb...
> 
> For these reasons I would suggest you use process limitations, such as
> ulimit and quotas under Un*x.

Thanks, I already thought about this... that's why I asked a survey on
povray.general...  to do a manual limitation... and my program could parse the
file and check it to see if there is no loop or anything...

Thanks,
	Simon


-- 
+-------------------------+----------------------------------+
| Simon Lemieux           | Website : http://www.666Mhz.net  |
| Email : Sin### [at] 666Mhznet | POV-Ray, OpenGL, C++ and more... |
+-------------------------+----------------------------------+

Post a reply to this message

On Thu, 16 Nov 2000 17:15:39 -0500, Simon Lemieux wrote:
>> You don't have to know how it's done to avoid it. :)
>
>And what if... I want to know... if there are security problems in povray, I
>need to know them...  You might have seen on povray.general that I've started
>working on an utility for povray... well, that's why I would need these security
>informations.

Well, then...

You probably need to make sure the script doesn't do any #fopens or #writes,
and make sure the output filename specified in the .ini file is okay (or remove
it entirely and replace it with a filename you make up.)  That'll be good
enough to catch most problems.  Watch for weird parser stuff like the fact
that this is valid syntax:

                                                 #

    fopen (whatever)


>What if I'm not on linux but on Windows? what about MacOS? what about the newer
>MacOS X?

MacOS X is of course BSD-based, so should support things like permissions and
chroot.  The other two aren't server operating systems, and running server
processes on them is just asking for trouble.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

On Thu, 16 Nov 2000 17:20:32 -0500, Simon Lemieux wrote:
>> There has been quite a long thread about this issues a few months
>> (weeks) ago. Warp and Ron gave good ideas.
>> IMHO memory and disk consumption are issues.
>> If you make a scene featuring an infinite loop adding objects to an
>> union, you will have POV crash after running out of memory.
>> Unfortunately it is likely that some other processes die to, including
>> system services.
>> If you open a file and write to it in an infinite loop, you can fill
>> your disk completly, which can be harmful in some cases (under Un*x,
>> filling /tmp or /var can have odd consequences). Even if you suppress
>> user I/O, one can still decide to render a nearly empty scene (for
>> speed) at a huge resolution: 65536*65536*24bpp takes 1.5 Gb...
>> 
>> For these reasons I would suggest you use process limitations, such as
>> ulimit and quotas under Un*x.
>
>Thanks, I already thought about this... that's why I asked a survey on
>povray.general...  to do a manual limitation... and my program could parse the
>file and check it to see if there is no loop or anything...

No it can't.  That's a famous theorem by from Computer Science, called the 
Halting Problem.  It's insoluble.  (Unless you plan to forbid loops entirely, 
in which case it'll be pretty useless.)

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

> You probably need to make sure the script doesn't do any #fopens or #writes,
> and make sure the output filename specified in the .ini file is okay (or remove
> it entirely and replace it with a filename you make up.)  That'll be good
> enough to catch most problems.  Watch for weird parser stuff like the fact
> that this is valid syntax:

Thanks!

>                                                  #
> 
>     fopen (whatever)

Hmmm... is this "<many_spaces>#fopen (whatever" 
or "<many_spaces>#\n\n fopen (whatever)"?

> >What if I'm not on linux but on Windows? what about MacOS? what about the newer
> >MacOS X?
> 
> MacOS X is of course BSD-based, so should support things like permissions and
> chroot.  The other two aren't server operating systems, and running server
> processes on them is just asking for trouble.

I know about MacOS X... and for the other two... well, I wont need
permissions...  The programm will handle that all by itself.. 

Thanks a lot!
	Simon

-- 
+-------------------------+----------------------------------+
| Simon Lemieux           | Website : http://www.666Mhz.net  |
| Email : Sin### [at] 666Mhznet | POV-Ray, OpenGL, C++ and more... |
+-------------------------+----------------------------------+

Post a reply to this message

> No it can't.  That's a famous theorem by from Computer Science, called the
> Halting Problem.  It's insoluble.  (Unless you plan to forbid loops entirely,
> in which case it'll be pretty useless.)

Hmm... true... anyway I don't wish to work on this...  but my program should be
able to deal with that kind of situations....  Believe me!  ;)

-- 
+-------------------------+----------------------------------+
| Simon Lemieux           | Website : http://www.666Mhz.net  |
| Email : Sin### [at] 666Mhznet | POV-Ray, OpenGL, C++ and more... |
+-------------------------+----------------------------------+

Post a reply to this message

On Thu, 16 Nov 2000 17:37:03 -0500, Simon Lemieux wrote:
>> You probably need to make sure the script doesn't do any #fopens or #writes,
>> and make sure the output filename specified in the .ini file is okay (or remove
>> it entirely and replace it with a filename you make up.)  That'll be good
>> enough to catch most problems.  Watch for weird parser stuff like the fact
>> that this is valid syntax:
>
>Thanks!
>
>>                                                  #
>> 
>>     fopen (whatever)
>
>Hmmm... is this "<many_spaces>#fopen (whatever" 
>or "<many_spaces>#\n\n fopen (whatever)"?

It's "<any whitespace>#<any whitespace>fopen<any whitespace>(whatever)"
Where "any whitespace" is any combination of spaces, tabs, CRs, and LFs.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

In article <3A145C8B.373F10E2@yahoo.com> , Simon Lemieux 
<lem### [at] yahoocom>  wrote:

> what about MacOS? what about the newer MacOS X?

On Mac OS you can look the System and Application folder, but that is it.
People could probably read and write to any other file and destroy them that
way, but as there is no login there is no break-in and they can't destroy or
change the system.

As for Mac OS X, as Ron said, it is BSD-based with a non-X GUI, so all the
Unix tricks work just fine.  However, in theory it should be easy to set up
a next to no privileges user thanks to the GUI.  Anyway, Mac OS X is not
final, and Mac OS X Server costs a lot of money (for non-developers)...


   Thorsten


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Simon Lemieux wrote in message <3A1432A7.2BA5CE7C@yahoo.com>...
>Hi,
> I was wondering, what are all the issues a hacker would have to hack my
>computer if he gave me a few files.gif, file.pov and file.ini to render?


If you are running an old version of the SuperPatch, watch out for #exec
commands in the .pov and .ini files.  Also, check to make sure that the
scene files are not #including files that they shouldn't (such as your
password file).

--
Mark

Post a reply to this message

> If you are running an old version of the SuperPatch, watch out for #exec
> commands in the .pov and .ini files.  Also, check to make sure that the
> scene files are not #including files that they shouldn't (such as your
> password file).

Thanks, nice one...  It could render the encrypted password in the image and
nobody would pay attention to it... thinking it's part of the render...

For the #exec, I will only use Official povray... no patches...

Thanks,
	Simon

-- 
+-------------------------+----------------------------------+
| Simon Lemieux           | Website : http://www.666Mhz.net  |
| Email : Sin### [at] 666Mhznet | POV-Ray, OpenGL, C++ and more... |
+-------------------------+----------------------------------+

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: It's "<any whitespace>#<any whitespace>fopen<any whitespace>(whatever)"

  Note also that there could be whitespaces inside the parentheses
(although I think that 'whatever' meant also that, but just mentioning).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

  "The derivative of sin(2x) is cos(2x)"  - Matt Giwer

Post a reply to this message

Francois Dispot <woz### [at] club-internetfr> wrote:
: Warp and Ron gave good ideas.

  I really hope that the guy who tried to hack that povray-site mentioned
in p.general did not get his ideas from that thread. I would feel quite
guilty if he/she did... :(
  (Although there wasn't anything in that thread that couldn't be
deduced reading the povray documentation...)

: If you make a scene featuring an infinite loop adding objects to an
: union, you will have POV crash after running out of memory.
: Unfortunately it is likely that some other processes die to, including
: system services.

  If it's a basic unix system, there shouldn't be any danger.
  I have run out of memory several times (even when running povray) and
nothing special has happened. The program just ended with an "out of memory".

  In Unix you can also limit the amount of memory a user can allocate.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

  "The derivative of sin(2x) is cos(2x)"  - Matt Giwer

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: No it can't.  That's a famous theorem by from Computer Science, called the 
: Halting Problem.  It's insoluble.

  It's insoluble in the general case (that is, there's no general solution
for testing the halting of an algorithm).
  Sometimes, however, it can be easy:

#while(true) #end

  However, it's very easy to make it more complicated.
  It can be made so complicated that it's not possible for ANY logic to
deduce whether it will stop or not (just think about a short code which
tests the Fermat Theorem for all combinations of the four numbers and ends
when it finds an answer).

  Theoretically it would be possible to limit the number of loops, eg.
don't allow the #while to make more than 1 million loops.
  This, however, would require parsing the code as povray does.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

  "The derivative of sin(2x) is cos(2x)"  - Matt Giwer

Post a reply to this message

On 17 Nov 2000 10:19:57 -0500, Warp wrote:
>  Theoretically it would be possible to limit the number of loops, eg.
>don't allow the #while to make more than 1 million loops.
>  This, however, would require parsing the code as povray does.

Or simply modifying the povray source code to exit with an error after
1 million iterations of the same loop.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: Or simply modifying the povray source code to exit with an error after
: 1 million iterations of the same loop.

  Yes, that would be certainly easier :)

  However, you have to take into account nested loops (think about 10 nested
loops, each one of them looping 1 million times).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

  "The derivative of sin(2x) is cos(2x)"  - Matt Giwer

Post a reply to this message

On 17 Nov 2000 10:37:03 -0500, Warp wrote:
>Ron Parker <ron### [at] povrayorg> wrote:
>: Or simply modifying the povray source code to exit with an error after
>: 1 million iterations of the same loop.
>
>  Yes, that would be certainly easier :)
>
>  However, you have to take into account nested loops (think about 10 nested
>loops, each one of them looping 1 million times).

And of course we can extend that arbitrarily.  What about one million loops,
each executing one million times?  What about one million jobs with one 
million loops each executing one million times?  What about isosurface and
antialiasing and media parameters that ensure 0pps for an entire image?

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Ron Parker wrote:

> What about isosurface and antialiasing and media parameters that
> ensure 0pps for an entire image?

I haven't seen 0 pps since I bought a faster computer.

Excuse me wrong topic :)

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

It's rather easy: +a0 +r1000

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

  "The derivative of sin(2x) is cos(2x)"  - Matt Giwer

Post a reply to this message

>   Note also that there could be whitespaces inside the parentheses
> (although I think that 'whatever' meant also that, but just mentioning).

So I think that scanning for "*fopen*" should do it? Right?

-- 
+-------------------------+----------------------------------+
| Simon Lemieux           | Website : http://www.666Mhz.net  |
| Email : Sin### [at] 666Mhznet | POV-Ray, OpenGL, C++ and more... |
+-------------------------+----------------------------------+

Post a reply to this message

Warp wrote:
> 
> Francois Dispot <woz### [at] club-internetfr> wrote:

>   If it's a basic unix system, there shouldn't be any danger.
>   I have run out of memory several times (even when running povray) and
> nothing special has happened. The program just ended with an "out of memory".

Wow, Solaris seems to be a lucky OS...
If you start a hard-core swapping session, and several processes request
memory at the same time, you cannot guess which one will get the "out of
memory" problem first. When this happens, I usually lose my rc5 proxy
server and other relatively useless things like ntpd, nothing lethal.

>   In Unix you can also limit the amount of memory a user can allocate.

This is exactly what I wrote (ulimit)

>   "The derivative of sin(2x) is cos(2x)"  - Matt Giwer

;-))

-- 
François DISPOT  --  http://www.wozzeck.net
      __  __ __  __  _
|  | /  \  /  / |_  /  |/
\/\/ \__/ /_ /_ |__ \_ |\

Post a reply to this message

Simon Lemieux wrote:

> So I think that scanning for "*fopen*" should do it? Right?

What about if fopen was part of a string
- eg text{ ttf "arial.ttf" "I have put fopen in this file as a text primitive
& now you can't render it" pigment{rgb 1}}
--
Bye
Pabs

Post a reply to this message

> What about if fopen was part of a string
> - eg text{ ttf "arial.ttf" "I have put fopen in this file as a text primitive
> & now you can't render it" pigment{rgb 1}}

Oh come on!... I guess that would be your problem! ;)

-- 
+-------------------------+----------------------------------+
| Simon Lemieux           | Website : http://www.666Mhz.net  |
| Email : Sin### [at] 666Mhznet | POV-Ray, OpenGL, C++ and more... |
+-------------------------+----------------------------------+

Post a reply to this message

On 16 Nov 2000 16:20:50 -0500, Ron Parker wrote:
>On Thu, 16 Nov 2000 17:15:39 -0500, Simon Lemieux wrote:
>
>>What if I'm not on linux but on Windows? what about MacOS? what about the newer
>>MacOS X?
>
>MacOS X is of course BSD-based, so should support things like permissions and
>chroot.  The other two aren't server operating systems, and running server
>processes on them is just asking for trouble.

Well Windows NT and 2000 are promoted as and used as server OSs
(although personally I think that any OS which needs a graphics card
isn't a real server OS), and they have a good permission system. Of
course the default permissions are totally wrong for a server (at least
for NT4, W2k looks a bit better), so if you want to run a server on them
you should know what you are doing.

	hp

-- 
   _  | Peter J. Holzer    | Perl ist der geglückte Versuch, einen
|_|_) | Sysadmin WSR       | braindump direkt ausführbar zu machen.
| |   | hjp### [at] wsracat      |    -- Lutz Donnerhacke in dasr.
__/   | http://www.hjp.at/ |

Post a reply to this message

On 17 Nov 2000 10:15:03 -0500, Warp wrote:
>Francois Dispot <woz### [at] club-internetfr> wrote:
>: Warp and Ron gave good ideas.
>
>  I really hope that the guy who tried to hack that povray-site mentioned
>in p.general did not get his ideas from that thread. I would feel quite
>guilty if he/she did... :(

Don't feel guilty. Security by obscurity never works for long, and if
you hadn't said it somebody else would have, or it would just have taken
a little bit longer until somebody had tried it. At least that thread
gave Steve the chance to fix the holes. That he didn't until he was hit,
is unfortunate, but that happens to the best of us.

>  In Unix you can also limit the amount of memory a user can allocate.

Not really. You can limit the amount of memory a single process can
allocate and the number of processes for each user. Unfortunately most
users need many small processes and few large ones, so the product of
both values is generally too large to be useful.

	hp

-- 
   _  | Peter J. Holzer    | Perl ist der geglückte Versuch, einen
|_|_) | Sysadmin WSR       | braindump direkt ausführbar zu machen.
| |   | hjp### [at] wsracat      |    -- Lutz Donnerhacke in dasr.
__/   | http://www.hjp.at/ |

Post a reply to this message

Pabs <pab### [at] hotmailcom> wrote:
: What about if fopen was part of a string

  It could also be a part of an identifier name.

#declare numberofopencylinders = 10;

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Francois Dispot <woz### [at] club-internetfr> wrote:
: Wow, Solaris seems to be a lucky OS...

  The only Unix OS I have heard that crashes when it runs out of memory
is Linux.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

>   It could also be a part of an identifier name.
> 
> #declare numberofopencylinders = 10;

As I said to simplify the programmation, that would not be allowed...

you should rather write numberOfOpenCylinders (if "*fOpen*" is allowed) or
nOpenCylinder... etc...

I hope you all understand it would be rather stupid to code something that would
understand if it's not the function fopen, while I haven't code half the main
program! ;)

-- 
+-------------------------+----------------------------------+
| Simon Lemieux           | Website : http://www.666Mhz.net  |
| Email : Sin### [at] 666Mhznet | POV-Ray, OpenGL, C++ and more... |
+-------------------------+----------------------------------+

Post a reply to this message

>   The only Unix OS I have heard that crashes when it runs out of memory
> is Linux.

I guess it depends on a few things, because I have RedHat 6.1 installed and I
tested it very much to make it crash and the only way I found was to play with
my 3dfx acceleration and even then I'm not sure if the computer is crashed or if
it's only the video that is...

When I start a 3dfx program, at the beginning it prints "unprotecting memory",
holds for ~1 second and start...  if I kill the program when it's unprotecting
the video memory, the video freezes...  

And that's the only crash I found...  there are some bugs that can hang the
computer for some time such as when the memory is getting very low... etc... but
nothing serious...

-- 
+-------------------------+----------------------------------+
| Simon Lemieux           | Website : http://www.666Mhz.net  |
| Email : Sin### [at] 666Mhznet | POV-Ray, OpenGL, C++ and more... |
+-------------------------+----------------------------------+

Post a reply to this message

I think that the most secure way of finding a true fopen is (using
regular expressions):

  (^|[^0-9A-Za-z])fopen($|[^0-9A-Za-z])

  I think that there's a shortcut in perl for [^0-9A-Za-z] but I don't
remember which it was.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

My information may be pretty old (several years). Of course bugs are
fixed and features improved over the time.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Note: If the "fopen" is inside a string, it will match that too...

  Making it ignore the word "fopen" if it appears inside a string may be
a lot harder.
  It may be too risky to even try, anyways (there may be too many ways for
fooling the filter to think that the fopen is inside a string when it actually
isn't).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 22 Nov 2000 09:14:14 -0500, Warp wrote:
>  I think that the most secure way of finding a true fopen is (using
>regular expressions):
>
>  (^|[^0-9A-Za-z])fopen($|[^0-9A-Za-z])
>
>  I think that there's a shortcut in perl for [^0-9A-Za-z] but I don't
>remember which it was.

\W


-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
:>  (^|[^0-9A-Za-z])fopen($|[^0-9A-Za-z])

: \W

  Right. The regular expression gets much simpler with that:

  (^|\W)fopen($|\W)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
:   (^|\W)fopen($|\W)

  Well, if we are using perl, we can simplify that even more:

  \bfopen\b

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

>   My information may be pretty old (several years). Of course bugs are
> fixed and features improved over the time.

I guess so...  my computer is running at 100% of CPU power since a few weeks
24/24 7/7...  And never crashed, I even used to overclock the cpu at some early
times... but I fried my 3dfx... <grin>  so got another 3dfx and stopped
overclocking...  (Celeron 433 could got up to 546mhz!!)  Actually that is not
absolutely true, I rebooted when my 30-days-of-render animation finished... to
prevent any inconvenient...  and as soon as it was ready I started another
animation... that one took only 4 days...

;)

Simon

-- 
+-------------------------+----------------------------------+
| Simon Lemieux           | Website : http://www.666Mhz.net  |
| Email : Sin### [at] 666Mhznet | POV-Ray, OpenGL, C++ and more... |
+-------------------------+----------------------------------+

Post a reply to this message

Warp wrote:
> 
>   It's rather easy: +a0 +r1000
> 

Oh, It's even easier: +a0.3 +am2

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Home page http://www.hot.ee/margusrt

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3a18ffc7@news.povray.org...
> Francois Dispot <woz### [at] club-internetfr> wrote:
> : Wow, Solaris seems to be a lucky OS...
>
>   The only Unix OS I have heard that crashes when it runs out of memory
> is Linux.
>
Not so much anymore. When it runs out of memory, it starts randomly killing
processes. They're working on the handling of out of memory errors for 2.4.
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

John Bauman <bau### [at] ptdprolognet> wrote:
: When it runs out of memory, it starts randomly killing processes.

  Randomly? Hopefully not processes like 'init' :)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3a4cebcd@news.povray.org...
> John Bauman <bau### [at] ptdprolognet> wrote:
> : When it runs out of memory, it starts randomly killing processes.
>
>   Randomly? Hopefully not processes like 'init' :)
>
Okay, semi-randomly. It would do that sometimes(I think) in older kernel
versions. Most of the time, the highest PIDs get killed first.
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message