 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nope, but you could just append (or prepend) the include files to your
scene file and submit that to the rendering farm. That kind of thing
should work.
- Steve
darcolo wrote:
>
> Your idea is just GREAT!
> Have you got any non-standard include files like galaxy.* or lego
> library.lib? Could you please list them somewhere? It would be helpful!
> Thank you very much for your great work
> Albiz
>
> Space Dude <swe### [at] rap ucaredu> wrote in message
> 39B91B56.D303C436@rap.ucar.edu...
> > Hey, folks!
> >
> > I just thought I'd let people know about my rendering farm again.
> >
> > It's at: http://www.badcheese.com/~steve/povray_form.shtml
> >
> > I'm using the stock povray 3.1g version.
> >
> > I've set up some machines to all query my web server and download a job
> > and render it and then e-mail the finished image back to you. It's
> > really cool!
> >
> > - Steve
> >
> > --
> > EMAIL: (h) ste### [at] badcheesecom WEB: http://badcheese.com/~steve
> > (w) swe### [at] rapucaredu
> > ste### [at] mailcom
--
EMAIL: (h) ste### [at] badcheesecom WEB: http://badcheese.com/~steve
(w) swe### [at] rapucaredu
ste### [at] mailcom
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Space Dude <swe### [at] rapucaredu> wrote:
: I'm using the stock povray 3.1g version.
You still haven't answered to my warning about security issues.
Let me put it clear: If you render with pov3.1g anything people send to
you, anyone can do anything he/she likes. It's perfectly possible to, for
example, destroy the entire home directory, get free access for anyone to
your account and so on.
It can be avoided by filtering the code people send. This, however, may
not be a 100% safe solution since there may be ways of encoding nasty
commands so that they can't be triggered by any filter.
--
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 wrote:
>
> Space Dude <swe### [at] rapucaredu> wrote:
> : I'm using the stock povray 3.1g version.
>
> You still haven't answered to my warning about security issues.
>
> Let me put it clear: If you render with pov3.1g anything people send to
> you, anyone can do anything he/she likes. It's perfectly possible to, for
> example, destroy the entire home directory, get free access for anyone to
> your account and so on.
>
> It can be avoided by filtering the code people send. This, however, may
> not be a 100% safe solution since there may be ways of encoding nasty
> commands so that they can't be triggered by any filter.
I guess that, at the very least, he has set up a dedicated account to
this system, with specified, limited memory and disk resources. But I
agree this does not solve everything!
--
__ __ __ __ _
| | / \ / / |_ / |/
\/\/ \__/ /_ /_ |__ \_ |\
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I guess that, at the very least, he has set up a dedicated account to
> this system, with specified, limited memory and disk resources. But I
> agree this does not solve everything!
I think the web page is designed to give povray a file.pov and a file.ini to
render that's all... the file.ini is generated by the program and the program
is locked, compiled... and the file.pov? Ok, give me a file.pov that can erase
all my hard disk!
I've made a file.pov that take like 2 year to render in 1024x768, but if he sees
that, he'd simply kill the prog...
IMO,
Simon
--
+-------------------------+----------------------------------+
| Simon Lemieux | Website : http://www.666Mhz.net |
| Email : Sin### [at] 666Mhznet | POV-Ray, OpenGL, C++ and more... |
+-------------------------+----------------------------------+
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Simon Lemieux <lem### [at] yahoocom> wrote:
: Ok, give me a file.pov that can erase
: all my hard disk!
A pov file that #fopens a startup file (such as .login) and appends there
some nasty shell commands... The file could also open povray.ini and
append the nasty commands there as a pre-scene or post-scene command.
--
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 wrote:
>
> Simon Lemieux <lem### [at] yahoocom> wrote:
> : Ok, give me a file.pov that can erase
> : all my hard disk!
>
> A pov file that #fopens a startup file (such as .login) and appends there
> some nasty shell commands... The file could also open povray.ini and
> append the nasty commands there as a pre-scene or post-scene command.
That was exactly what I had in mind... also create a nice script named
"povray", just for fun, to see how your path is set...
But it could also create an infinite number of files. Or infinitely long
ones. It costs you nothing to saturate the filesystem.
Note that I (and I think Warp too) am not bashing an idea I think good
and useful :-)
I would be very sorry if you got in trouble just because you opened a
nice rendering farm to everyone.
--
__ __ __ __ _
| | / \ / / |_ / |/
\/\/ \__/ /_ /_ |__ \_ |\
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 16 Sep 2000 20:26:34 +0000, Francois Dispot wrote:
>Warp wrote:
>>
>> Simon Lemieux <lem### [at] yahoocom> wrote:
>> : Ok, give me a file.pov that can erase
>> : all my hard disk!
>>
>> A pov file that #fopens a startup file (such as .login) and
>> appends there some nasty shell commands... The file could also open
>> povray.ini and append the nasty commands there as a pre-scene or
>> post-scene command.
>
>That was exactly what I had in mind...
I don't know how Simon has set up his farm, of course, but I did
something like this, I'd run the povray processes as a separate user
which doesn't have write permissions to any file except the working
directory.
>also create a nice script named "povray",
The working directory shouldn't be in the PATH of povray.
>just for fun, to see how your path is set... But it could also create
>an infinite number of files. Or infinitely long ones. It costs you
>nothing to saturate the filesystem.
True (well, until you hit the quotas - but unless every job runs under a
different uid that would still stop all other rendering jobs). There is
no easy way to prevent that, but you can detect working directories over
a certain size and kill their jobs.
>I would be very sorry if you got in trouble just because you opened a
>nice rendering farm to everyone.
I have a suggestion: Would it be possible to upload a tar (or zip) file
with all the files decribing a scene? I tend to split my scenes into
many small files.
hp
--
_ | Peter J. Holzer | access ist als datenbankserver fraglos noch
|_|_) | Sysadmin WSR | ungeeigneter als beispielsweise EDIT.COM,
| | | hjp### [at] wsracat | und das primaer aufgrund der erzeugung
__/ | http://www.hjp.at/ | falscher erwartungshaltungen. frank paulsen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Francois Dispot <woz### [at] club-internetfr> wrote:
: Note that I (and I think Warp too) am not bashing an idea I think good
: and useful :-)
Yes, the idea is wonderful.
You should take into account security issues, though.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Peter J. Holzer" wrote:
> I have a suggestion: Would it be possible to upload a tar (or zip) file
> with all the files decribing a scene? I tend to split my scenes into
> many small files.
IIRC it is exactly what the people at imp did in their own compile.
--
__ __ __ __ _
| | / \ / / |_ / |/
\/\/ \__/ /_ /_ |__ \_ |\
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> IIRC it is exactly what the people at imp did in their own compile.
That's true. You can find out more at:
http://www.imp.org/members/tech/rcast/imppovray.asp
In summary:
+ Can read POV, INI, BMP, GIF etc from inside tar file.
+ Can handle directory strutures withing the tar file.
+ Does not require unpacking the TAR file.
+ Tar handling is implemented in C++.
+ Tar handling works for Win32 or Linux, probably other platforms too.
- POV True-type handling code depends on absolute offsets in file.
(Therefore .TTF files are not handled correctly)
- Implies slight changes to the way POV searches for included files.
- Complete integration with POV would require adoption of some
conventions.
The main issue with the IMPPOV concept was finding a generic way
of synchronising different machines sharing a common filesystem
so that they don't overwrite each other's results. (Still no known
method of implementing a filesystem based mutex)
Cheers,
Nigel Stewart
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
