[snip] A customer has asked how he could implement some stringent security on the 'unirpc' services. In particular, he wants to only allow certain 'Requests' (like the 'Subroutine' method, etc.) from any users out there writing UniVerse Objects front-ends. [snip]
Overall, I think, like the others, that this isn't really a good idea. I don't have much time to think about this (therefore it is probably not going to work ;-) but what about trying to use permissions. Set all files (except what you absolutely need to gain access to the account) to not permit read/write/execute. In the subroutine, see if it's possible to 'su' to a user that does have the permission for file access. If this is possible, it now moves the security issue to another point, as this 'su' user is going to have the password available somewhere. And here is another crazy idea. Create an account with nothing in it (except what is minimally required). As part of your subroutines on the server, have them write out the file pointer (which is pointed to another account) to the VOC and then remove them when complete. You should keep the file pointer unique (so another process doesn't remove your pointer when it is done) and also keep it random (so that someone doesn't create a long process and then knowing the pointer, start operating on it). Of course, there is nothing to stop someone from opening the VOC from within UniObjects and writing their own pointer to the actual account/file so you would have to keep the actual filenames and real account path/name a secret. There are still ways to beat this so be careful. Finally, how about something to do with triggers (for writing anyway). Reject all writes unless they come from an acceptable routine. Again, these are not very good ideas, but, hey, it's Friday! Regards, Jim -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
