[DGD] Inherit/include

[Shevek]

>The only access that counts at that point is the access that the file
>has, it doesn't matter that you (the coder) have a bit more access
>than that, otherwise you could have the following situation:

 From what I see using status in the kernel lib the owner of a file gets 
set to wherever it is compiled from it just doesn't seem to change a great 
deal of anything. There isn't anything insecure about letting a file take 
the access of the user who compiles it, so long as the user doesn't go 
around compiling code they haven't checked.

Things are stranger than it just being the file's access that's odd though.

Eg I copied a file called test into ~/System, which contained a single 
command to write a file into the ~/System directory. On compilation with 
any user that has access to System it quite happily writes a file into the 
~/System directory. Tried this again with a user that has write access to 
~/System but not write access to ~/Private. Upon compilation in ~/System 
the test program can merrily write its test file into ~/Private.
To me that sounds exactly like the behaviour you describe below, with the 
test program taking System's root access.

But it gets more complex. When you give a user (I'll call him Test) write 
access to a directory (I'll call it ~/Public). Test can use the editor to 
make files in ~/Public, but can't compile code in their home directory that 
writes files to ~/Public.
Now say Test is given read access to a directory (I'll call it ~/Private) 
they can read anything they like, but any code they write in ~/Test can't 
read from the directory (Although it can if ~/Private is global read).
Ie the file access problem you pointed out.

Effectively this makes any code, written in a user directory that isn't 
~/System, trapped in its own directory, only able to read from global read 
directories, with any code written in ~/System having full root access 
(Despite includes/inherits from anything other than the kernel).

I can see why trapping code inside the directories is secure, I just think 
that if code can access that which the owner (Ie compiler of the code) can 
access then it makes things a whole bunch easier to use. Otherwise anything 
that has to read/write from outside its user directory (From anything that 
isn't global read) has to go into System, or use a daemon in System to give 
it file access outside its user directory.

>- You (bar) grant <foo> write-access in your home-directory to work on
>   something.
>- You, one of the main game-admins, also have full access to /.
>- <foo> now writes a bit of code in your home-directory and, using
>   that, has full access to /.
>
>Sweet, isn't it?

Define sweet :>

I get your point, although that wasn't the behaviour I was suggesting.

If I have code in System, and get it to be compiled with System as owner 
then it has full / access anyway. Just can't inherit/include anything from 
anywhere but ~/include or a global read dir which still seems bizarre to 
me. So I can have a piece of code which is able to read/write/delete any 
file it likes (Tested this), but cannot inherit/include the file. Does that 
not sound even a little odd to you?

>Use your ~/open/ directory if you want to share some feature/interface
>information, I'd suggest creating ~/open/lib/ and ~/open/include/ for
>this purpose and for any code you want to share you can put an almost
>empty inheriting bit in ~/open/lib/fnurt.c which can be used by
>others.
>
>Consider it the 'black box' approach. :-)  If you want to share all of
>the code then put all of it in your ~/open/ directory.
>
>Hope that helps,
>
>Erwin.

Do this already with stuff like a room inheritable etc.
Thing is all I want to do is inherit/include from a private directory that 
doesn't give any special write access :>

Cheers,
         Shevek

_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd