On Aug 7, 2006, at 4:29 PM, Howard Stearns wrote:

> Michael,
>
> In my opinion, you're solving the wrong problem. Fun, perhaps, but  
> not likely to help you win big. (FWIW, IMHO, YMMV, etc...)
>
> It seems to me that any attempt to put arbitrary, coarse-grained  
> restrictions on computer resources -- as opposed to problem-domain  
> or user-domain behaviors, is just doing a lot of work to shift the  
> problem, without actually solving it.  How will the programmer set  
> these limits? How will the poor user or "administrator" manage them?
>
> I imagine that there must be a lot written in or about the Java  
> community that gives examples of this. But in short, since users  
> and administrators don't know whether or how much to limit non- 
> behavior-oriented computer resources, they are forced to either  
> trust an application completely, or to restrict it pretty-much  
> completely, which makes it fairly useless. There is a  better way.
>
> Now, there are two issues:
>
> 1. "But my customer wants to do it the broken way!" Fair enough.  
> You might consider, though, whether or not this approach fits with  
> the real advantages (to the customer, not to you) of using Squeak.  
> If you turn the application into something that works just like  
> Java except that it's in Squeak, you can bet the contract that in  
> the end, the customer will decide to re-implement it in Java (for  
> social reasons, such as covering their butts in deploying, hiring  
> people to work on it, etc.)  Doing a broken, Java-like thing  
> "better than Java" is just a special case.
>
> 2. "OK, How SHOULD I do it?" Here you have to look at the actual  
> problems you're trying to avoid. For example, suppose you want to  
> keep mobile programs from writing files on a user's computer. The  
> answer is to arrange to only present a 'file open' interface that  
> prompts the user for the location. This is better than draconianly  
> prohibiting all 'file open' requests, because it still allows  
> arbitrary programs to do useful work as long as the user is made  
> clearly aware of what the program is doing. (In an imperfect-world  
> nod to resource management, that user dialog might specify the max  
> size of the file.)

I very much agree. Some ways back I have written an authorisation  
system for a car leasing company along exactly these lines. They  
liked it.
The nice part was that it was even administrable by end-users: Select  
a widget,  give the functionality (either readable or clickable) of  
that widget a name, link name to a role, link the roles to persons,  
and voila....

Sure, you better don't forget any UI parts, but I do think that the  
end-to-end argument from Reeds and Co. applies to many aspects in  
software development -like security - also.
http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf

At least in theory ;-) something should be locked, if all the outer  
ports of the castle surrounding it are locked.

Cheers,

Markus

> Now suppose you want to have the system manage (e.g., remember) the  
> fact that such-and-such an object has requested a file-open, and  
> that the user has granted it for given name/size. The capabilities  
> community (see e-rights) has a lot of literature on how to do this  
> securely. But as I see it, the capabilities stuff is just an  
> implementation detail for the higher-level issue of  choosing what  
> (or where) to manage problem-specific behaviors. (See end-to-end  
> argument.)
>
> -Howard
>
> Michael van der Gulik wrote:
>> Hi all.
>>
>> Here's a generic problem for people that like puzzles that I can't  
>> seem to work out: I want to add "Domains" to Squeak, so that  
>> system resources can be managed.
>>
>> Here's how it would work, in theory:
>>
>> * A domain would typically be a group of objects related to a  
>> particular application.
>> * Every object belongs to a domain.
>>
>> And then:
>>
>> - A domain's memory usage can be capped. Object>>new would be  
>> implemented so that it would wait for free memory or throw an  
>> Exception if the memory cap has been breached.
>>
>> - A domain can only start up a limited number of Processes. This  
>> would control fork bombs etc. Process>>new or some other entry  
>> point would check for this and wait or throw an Exception if the  
>> process limit has been breached.
>>
>> - Ditto for other system resources, such as disk usage, network  
>> bandwidth, access to devices etc.
>>
>> - I'm implementing a distributed system, so remote objects that  
>> come in will already belong to a particular domain. A local  
>> DomainManager or some other mechanism would determine if objects  
>> from that domain are allowed to use local system resources, and at  
>> which priorities.
>>
>> For example, I could have two domains: "AlicesEmail" an  
>> "BobsEmail". AlicesEmail is capped at 10Mb of memory and 6  
>> processes. BobsEmail is capped at 20Mb of memory and 15 processes.  
>> Assuming that the Squeak image is a remote mail server; now  
>> neither Alice nor Bob can make the image explode by doing funny  
>> things with their email. Both domains use the same classes.
>>
>> Now, here's the problem:
>>
>> How would I implement Object>>new and Process>>new (or other  
>> equally good locations) so that the domain for that object is  
>> found and a DomainManager queried about that domain's privileges?
>>
>> The possibilities that I've thought of so far are:
>>
>> 1. Adding an instance variable called 'domain' to Object is a bad  
>> idea - consider SmallIntegers and parts of the VM that assume  
>> certain instance variables are in certain places.
>>
>> 2. Creating dictionaries of which objects are in which domains  
>> would work, but is going to be extremely inefficient. _Every_  
>> object in the image would have an entry in these dictionaries.
>>
>> 3. Creating a subclass of Object with an instance variable  
>> "domain" could work, and then all other objects that are used by  
>> domain-using code are subclasses. I'm still thinking through the  
>> implications.
>>
>> 4. Assigning domains to processes rather than objects is a  
>> possibility, but this would allow resource theft when invocations  
>> are done on objects out of the current domain. If this was done,  
>> the current domain would just be <<thisContext domain>>.
>>
>> 5. Another option is to make radical changes to the VM, so that a  
>> domain of objects are all kept in the same range of memory. This  
>> would be a rather major change and would introduce bugs.
>>
>> 6. I could do fancy tricks with the garbage collector like  
>> ImageSegment does and trace references back to an object which  
>> identifies the current domain. This is slow and yuck.
>>
>> So far alternatives 3 or 4 seem possible.
>>
>> Thinking aloud; option 4 could be implemented by implementing  
>> Domain>>doPrivileged: taking a block as an argument. Object>>new  
>> and Process>>new can then search down the stack until  
>> Domain>>doPrivileged: is found and ask the global DomainManager  
>> what that domain is allowed to do. Calls out of the current domain  
>> can be stripped of privileges by doing something like  
>> noPrivilegesDomain>>doPrivileged: [otherObject doSomething].  
>> otherObject would then need to call doPrivileged: again with its  
>> own domain to regain the ability to fork and make new objects.
>>
>> Umm... this would need some way of preventing user processes from  
>> peeking down the stack and stealing another domain (i.e. using  
>> capability-based security).
>>
>> Option 3 has the advantage of making less work for the poor  
>> application developer, but incurs an extra pointer for every  
>> single object.
>>
>> Java does something similar, but it does it based on classes or  
>> jar files (afaik). This is not particularly good - you can't have  
>> two domains with different privileges which share the same  
>> implementation. For example, you can't have an "AlicesEmail" and  
>> "BobsEmail" domains with different privileges if they both use the  
>> same classes.
>>
>> Thoughts? Does anything like this already exist?
>>
>> Mikevdg.
>>
>>
>
> -- 
> Howard Stearns
> University of Wisconsin - Madison
> Division of Information Technology
> mailto:hstearns at wisc.edu
> jabber:hstearns at wiscchat.wisc.edu
> voice:+1-608-262-3724
>
>