![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
hi,
"Bald Eagle" <cre### [at] netscape net> wrote:
> ...
> Is it possible, and is there a security issue related to providing a means to
> create a subdirectory in a write-permitted directory?
>
> #write creates a file. Can we create a directory by a similar means?
> Just something to think about.
have been thinking about (wishing for) for a 'system()' type function for a long
time. but reading the above made me realise that a modified '#fopen' which
supports command pipelines, aided by a new OPEN_TYPE for r/w access could do
"everything" anyway. then we could write, eg:
#fopen FP "| program" rdwr
to communicate with 'program', making creating a directory, all sorts of stuff,
easy and convenient. for instance write some calculated parameters to 'program'
and read back new, derived values.
regards, jr.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Le Forgeron
Subject: Re: An updated povr tarball for Unix/Linux. f6b1c13e
Date: 31 Jul 2020 12:55:21
Message: <5f244cf9$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Le 31/07/2020 à 16:40, jr a écrit :
> hi,
>
> "Bald Eagle" <cre### [at] netscape net> wrote:
>> ...
>> Is it possible, and is there a security issue related to providing a means to
>> create a subdirectory in a write-permitted directory?
>>
>> #write creates a file. Can we create a directory by a similar means?
>> Just something to think about.
>
> have been thinking about (wishing for) for a 'system()' type function for a long
> time. but reading the above made me realise that a modified '#fopen' which
> supports command pipelines, aided by a new OPEN_TYPE for r/w access could do
> "everything" anyway. then we could write, eg:
>
> #fopen FP "| program" rdwr
>
> to communicate with 'program', making creating a directory, all sorts of stuff,
> easy and convenient. for instance write some calculated parameters to 'program'
> and read back new, derived values.
>
>
"Danger Will Robinson"
This could lead to some system corruption... A reason that there is
already io-restrictions: to protect the innocent.
You already have "shell-out" capability, with pre & post, scene & frame
level, so grouping actions should be doable to have all you need.
http://wiki.povray.org/content/Reference:Shell_Command_Options
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
hi,
Le_Forgeron <jgr### [at] free fr> wrote:
> Le 31/07/2020 à 16:40, jr a écrit :
> > ... but reading the above made me realise that a modified '#fopen' which
> > supports command pipelines, aided by a new OPEN_TYPE for r/w access could do
> > "everything" anyway. then we could write, eg:
> >
> > #fopen FP "| program" rdwr
> >
> > to communicate with 'program', making creating a directory, all sorts of stuff,
> > easy and convenient. for instance write some calculated parameters to 'program'
> > and read back new, derived values.
>
> "Danger Will Robinson"
>
> This could lead to some system corruption... A reason that there is
> already io-restrictions: to protect the innocent.
:-) true. otoh, the imagined '|program' form of '#fopen' could be made subject
to the same '[Shellout Security]' setting as the pre/post commands.
> You already have "shell-out" capability, with pre & post, scene & frame
> level, so grouping actions should be doable to have all you need.
also true, I guess, that those commands can be used to do "everything". still,
there are differences. for instance, now, if I need to pass multiple/many
calculated values to 'program', I have to write a temporary file to be processed
by 'program', and then read the results on the next frame. a modified '#fopen'
would allow a different programming style, and would in the example obviate the
need for temporary file(s) and animation control.
regards, jr.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
hi,
William F Pokorny <ano### [at] anonymous org> wrote:
> Please find attached an updated tarball.
> ...
ran into a problem with some code I was sent.
==== [Parsing...] ==========================================================
#include "spheresweep.inc" //version 1.2
File '/home/jr/POVr/share/povray-3.8/include/shapes.inc' line 20:
Possible Parse Error:
Cannot find file 'Wrapper.inc', even after trying to append file type extension.
File '/home/jr/POVr/share/povray-3.8/include/shapes.inc' line 20:
Parse Error:
Cannot open include file Wrapper.inc.
Fatal error in parser: Cannot parse input.
Render failed
regards, jr.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"jr" <cre### [at] gmail com> wrote:
> ran into a problem with some code I was sent.
>
> ==== [Parsing...] ==========================================================
> #include "spheresweep.inc" //version 1.2
> File '/home/jr/POVr/share/povray-3.8/include/shapes.inc' line 20:
> Possible Parse Error:
> Cannot find file 'Wrapper.inc', even after trying to append file type extension.
> File '/home/jr/POVr/share/povray-3.8/include/shapes.inc' line 20:
> Parse Error:
> Cannot open include file Wrapper.inc.
> Fatal error in parser: Cannot parse input.
> Render failed
That's a _weird_ error, especially since line 20 of shapes.inc is
#include "shapes_old.inc"
And there's no reference to 'Wrapper.inc' in either file.
Maybe if you have a reference to that, just comment it out?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: William F Pokorny
Subject: Re: An updated povr tarball for Unix/Linux. f6b1c13e
Date: 1 Aug 2020 09:16:05
Message: <5f256b15@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 7/30/20 8:44 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymous org> wrote:
>
>> Just back from a few days at real life. Back at povr for real tomorrow -
>> or the day after. Ahead of me getting back...
>
> Is it possible, and is there a security issue related to providing a means to
> create a subdirectory in a write-permitted directory?
>
> #write creates a file. Can we create a directory by a similar means?
> Just something to think about.
>
Yes, and no security issue with unix/linux/*x at least(1).
(1) - Maybe some obscure ways to disable a file system if one works at it.
The more tangled part is what would a command set supporting directories
look like. Then we'd have the implementation of those commands,
documentation and training of users. I saw too jr's suggestion for
system commands. I don't know...
I'll further hedge. Again due my tcl wrapper, I've not used the POV-Ray
based IO all that much. You and others, understand SDL IO better than me.
Aside:
My few, true animations I've done with my wrapper so I can do other
frame to frame work in tcl (as jr suggested useful) and more so to
see/work with the "as calculated" per-frame scene files while
debugging/developing. Being able to get an after SDL(tcl) 'runs' scene
representation is helpful.
My pure POV-Ray animation use has been: Creating a few frames where
early images are used in a final one; Tickets and promo stuff for an
arts program; A large puzzle piece image for a town treasure/scavenger
hunt where the 'animation' created the puzzle piece images which were
printed on smaller photo sized paper edge to edge. POV-Ray and its
animation capability is very useful for such projects.
Bill P.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: William F Pokorny
Subject: Re: An updated povr tarball for Unix/Linux. f6b1c13e
Date: 1 Aug 2020 10:06:06
Message: <5f2576ce$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 7/31/20 12:55 PM, Le_Forgeron wrote:
> Le 31/07/2020 à 16:40, jr a écrit :
>> hi,
>>
>> "Bald Eagle" <cre### [at] netscape net> wrote:
>>> ...
...
>> have been thinking about (wishing for) for a 'system()' type function for a long
>> time. but reading the above made me realise that a modified '#fopen' which
>> supports command pipelines, aided by a new OPEN_TYPE for r/w access could do
>> "everything" anyway. then we could write, eg:
>>
>> #fopen FP "| program" rdwr
>>
>> to communicate with 'program', making creating a directory, all sorts of stuff,
>> easy and convenient. for instance write some calculated parameters to 'program'
>> and read back new, derived values.
...
>
> "Danger Will Robinson"
>
> This could lead to some system corruption... A reason that there is
> already io-restrictions: to protect the innocent.
>
Though I've used *x systems for a long time, I make no claims on being a
system image / os expert. I get that there might have been reasons for
the io restrictions long ago, but how much protection do the io
restrictions 'really' offer these days?
A properly set up unix/linux/*x system - whether POV-Ray is installed or
not - already sets permissions which prevent regular users from reading
and writing system directories and files.
Excepting, when they are allowed to run as root, in which case they
already have an infinite number of ways to corrupt the system. And, as
root, they can even do it using POV-Ray too as it ships/is-packaged today.
On systems, true multi-user or not, a regular user can fill up /tmp for
example. They can chew up all the real ram, perhaps even all the swap
with enough time (assuming the system admins are not running monitors
which kill bad acting processes).
I look at our io restrictions and I think they likely cause as many
users problems as they solve(1), while making it only a little easier
for POV-Ray as an entity to say "it's unlikely POV-Ray wiped out your
system."
(1) - When users or well intention-ed system admins prevent folks from
being able to read and write where they should be able to read and write.
What am I missing?
Bill P.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: William F Pokorny
Subject: Re: An updated povr tarball for Unix/Linux. f6b1c13e
Date: 1 Aug 2020 10:12:13
Message: <5f25783d$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 7/31/20 4:19 AM, jr wrote:
> hi,
...
>
> no, for me it's just[*] the lower/uppercase stuff. basically, each of my old
> scenes I tried, failed. I thought about modifying scene code, but since they
> work I'll find it easier not to use (the new version of) 'povr'.
>
> [*] at present.
>
>> Are there actual conflicts/problems with the approach; or examples where
>> it's very inconvenient?
>
> just inconvenient. eg, to "fix" the scene I used when I ran into the X11
> animation issue, would be a lot of work, made worse by the fact that I got that
> scene from the web, ie it's not even my code.
>
>> The functionality is still hacked in - because I'm trying it too. :-)
>> But, thus far, I'm liking the behavior.
>
> cannot say the same. guess I'm "allergic" to uppercase. :-)
>
> (could this behaviour be enabled/disabled via a 'povray.conf' setting instead?)
>
Maybe in the near term, but the whole idea is to offer a way to code
function and macro parameters which will never collide. This method only
works if people cannot turn off the case checking.
I don't think there is any magic here. Name spaces, or whatever method,
any fix(es) for indentifier name collisions will require changes to
existing code and coding habits.
Bill P.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: William F Pokorny
Subject: Re: An updated povr tarball for Unix/Linux. f6b1c13e
Date: 1 Aug 2020 10:54:45
Message: <5f258235$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 7/31/20 6:29 PM, jr wrote:
> hi,
>
> William F Pokorny <ano### [at] anonymous org> wrote:
>> Please find attached an updated tarball.
>> ...
>
> ran into a problem with some code I was sent.
>
> ==== [Parsing...] ==========================================================
> #include "spheresweep.inc" //version 1.2
> File '/home/jr/POVr/share/povray-3.8/include/shapes.inc' line 20:
> Possible Parse Error:
> Cannot find file 'Wrapper.inc', even after trying to append file type extension.
> File '/home/jr/POVr/share/povray-3.8/include/shapes.inc' line 20:
> Parse Error:
> Cannot open include file Wrapper.inc.
> Fatal error in parser: Cannot parse input.
> Render failed
>
>
> regards, jr.
>
Ah, dang. Thanks!
While I'm working on new inbuilt functions, I use the Wrapper.inc
include. It's found via my own POVINI variable setting and is used to
point to a git tracked functions.inc file instead of the normal
./include directory. The latter is not at the moment code controlled -
though that's the plan.
In short, Wrapper.inc is a hack that lets me develop without having to
create a build package on inbuilt function re-compiles. This mistake
happened when I implemented an inbuilt f_supertorus() and updated the
existing Supertorus shapes.inc macro to call it over, the old explicit
function {} isosurface code.
I reviewed the other povr shipped includes just now - and I found one
other mistake... I'd un-commented, or as likely commented in the wrong
directory, the const.inc include in rand.inc and it declares 'e' which
fails the lower case check. That include const.inc isn't needed today
even in POV-Ray best as I can tell(1).
(1) - I fact looked to me as if several POV-Ray shipped includes are
doing pointless includes which of course burns parse time for no reason.
Bill P.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
William F Pokorny <ano### [at] anonymous org> wrote:
> The more tangled part is what would a command set supporting directories
> look like.
I don't use any of the shellout commands, but I would imagine it would just be a
call to the "DOS" to create the specified directory.
mkdir "newDirectory"
#CreateDirectory "newDirectory"
The only bell-and-whistle thing I could envision would be opening a file for
writing in a subdirectory that doesn't yet exist, and automagically creating the
necessary directory branches for the file. Probably wisest to purposefully
enable this feature to guard against simple typographical errors.
> Then we'd have the implementation of those commands,
I'm guessing you mean the actual POV-Ray source code
> documentation and training of users.
Which would be --- 3 or 4 lines of text? :D
I mean, I know that packages of food come with instructions nowadays, "1. tear
open package 2. remove contents 3. eat" but I'm pretty sure most of it ought to
be "self-evident".
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |