Re: seduid scripts

[mh1@irz.inf.tu-dresden.de (Michael Hohmuth)]

Hi again,

I gave my Pscript() proposal a second thought and discovered that there 
are at least three serious problems with it:

1)  If we do not let the kernel figure out itself which interpreter to 
use with the script (i.e. if we let the user do this), the user can run 
any program with the set*id flags of the script, be it the one from the 
"#!" line or not.  This seems to be a serious security problem.

2)  The kernel would only know the TOS form of the script's file name and 
would pass this one to the interpreter, which is probably not what we want 
(in most cases, we want to pass a Unix file name).

3)  The caller has to submit ARGV in the environment, which includes the 
script's file name (in most cases, this will be the one the interpreter 
sees).  The kernel has no chance to see/change this one.  (We could 
build ARGV handling into the kernel, but that's just another 
inconsistency.)

Please forget my first proposal (which had been developed a bit hastily 
:-).  I have to admit that I have currently no idea how to achieve setuid 
script capability without inconsistencies in the kernel.  I'm beginning to 
think that some sort of file name translation in the kernel would be the 
easiest way.

[ dream on ]

(Perhaps it's the easiest to introduce a new process domain (Posix) 
which allows/demands '/' as the path separator and doesn't know about 
"drives" but always assumes "U:/" is the root directory (or at least 
takes all absolute file names not containing drive specs relative to 
"U:/").  This would also be a chance to do the whole argument passing 
scheme over again, and it would make TOS file systems, ".ttp" extensions 
and backslashes "nonstandard" and a subject of "optional special 
backward compatibelity efforts", as it already happens to be on my 
machine.  Should I add a smiley here? :-)

[ dream off ]

Michael
-- 
Internet: hohmuth@freia.inf.tu-dresden.de