POV-Ray : Newsgroups : povray.binaries.programming : An updated povr tarball for Unix/Linux. f6b1c13e : Re: An updated povr tarball for Unix/Linux. f6b1c13e Server Time
19 Apr 2024 08:04:18 EDT (-0400)
  Re: An updated povr tarball for Unix/Linux. f6b1c13e  
From: William F Pokorny
Date: 1 Aug 2020 10:06:06
Message: <5f2576ce$1@news.povray.org>
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.