hi,

"Bald Eagle" <cre### [at] netscapenet> 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

Le 31/07/2020 à 16:40, jr a écrit :
> hi,
> 
> "Bald Eagle" <cre### [at] netscapenet> 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

hi,

Le_Forgeron <jgr### [at] freefr> 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

hi,

William F Pokorny <ano### [at] anonymousorg> 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

"jr" <cre### [at] gmailcom> 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

On 7/30/20 8:44 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> 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

On 7/31/20 12:55 PM, Le_Forgeron wrote:
> Le 31/07/2020 à 16:40, jr a écrit :
>> hi,
>>
>> "Bald Eagle" <cre### [at] netscapenet> 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

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

On 7/31/20 6:29 PM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> 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

William F Pokorny <ano### [at] anonymousorg> 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