Suppose I can work on the trust server.


One thing that will be an issue are permissions. Basically when I need to do implies and such, I can either have duplicate code or create instances of the permission classes. So basically for the trust group I will need a way for it to create a temporary Permission instance. But there is potential for it to be not trusted. Like there could be a user made permission, which could do evil things, which would then be initialized and evil things done in the kernel potentially with as many permissions as possible. So there is great potential for abuse to occur. So either the trust server will have to implement implies for certain permissions, or it would fall within the client task to verify permissions that are valid. Of course then an exploited client would then be able to say that all permissions are valid. Like they could make a Permission which always implies other Permissions which would be a bad thing. So the big question is, how do permissions get checked the way they are with all of the varying classes.


So permissions will definitely need to be handled somehow, cannot trust the client and cannot trust the classes to be okay for initialization in the server. One thing I could potentially do however, is have a virtual machine of sorts in the client context. One which consist of classes for the client and then initialize a fake Java object of sorts to check a permission in. So the implies would run in that mini-VM of sorts. This would be quite slow but it would technically be secure. This would work at a cost of speed since the VM would not really be that fast. It is really the only way I can think of that would allow the kernel to check permissions and such. Technically what I can do is have a very limited VM with a minimal set of hardcoded classes and methods which permissions must execute under. The only thing would be, how the classes execute. I may also need to load super-classes too so that those can be handled accordingly. It will just be a very very basic VM for the most part. Since I do not want these to be actual resources, I will need a special protected resources provided by a task. So I create a means of having these resources accessible to tasks accordingly so that way the VM can run for the permission class. Each task can cache the resources and the VM state. Unlike the normal VM which is mostly checked, this will be very simple and not support all considerations of things. Basically it is intended to be fast because I do not want to pull in a complete interpreter with full VM support. So then this will mean that any class which extends Permission when compiled will need a compilation of the light VM code. I think this is the best way to do it and the classes which implement implies should not be doing very complex things either. Also, I suppose as a rule the permission checker should never imply another permission exists unless it is of the same class. This way one cannot create a super-permission which implies all other permissions to exploit it. So for the permission manager I will need to write and implement a compiler. I would suppose that this would go in the JIT and it would just be a very basic VM for the most part. But since it would be part of the JIT I can use classes such as the class thing. I will just use a different handler of the byte code.


Only thing is, how do I link the trust group and the system task so that way it knows where to get resources from? I suppose it could be handled in the kernel or really just the trust group server for the most part.


Since there will be shared JIT code, I will need code which can provide access to class file data and such accordingly.


It would also be good if the there were a way for packets to send streams for input and output to each other. That would actually be slower than sending a gigantic bulk byte array but for some really large resources and such, there might not be enough memory when not all of it needs to be used. I should use that instead of having gigantic byte arrays. It would really be useful for installing JARs and such. It could just for the most part linearly process the files.


I would basically need another service which can use the packet based interface, but allows for streams to be sent to the server and such. Then when the kernel requests a read from a client it can be sent as an actual request back and it can continue reading.