Virtualization

Full access to the virtual bubble only. It doesn't matter if they break anything in the bubble as it's set back on next launch anyway (with the exception of user data).

It doesn't matter if they break anything in the bubble as it's set back on next launch anyway (with the exception of user data).


True partially but not entirely.. If my application running from the bubble go out and delete it's own executable or dlls or whatever, then it would appear to subsequent launch tries that those files are indeed missing from the bubble, causing the launch to fail. In technical sense, they have not been deleted from the cache (as far as I know of) but the deletion has been cached in either UsrVol or GlbVol -files for that package (for executables most likely in GlbVol since exes and dlls are by default marked as Application Data), thus making it look like that they do not exists anymore. And in case of GlbVol caching, the only reset option available for normal user, Repair, won't do that much good..

What you need to do in that case is of course take Repair, clear, delete or any other appropriate action that loses all of the changes to package's VE in client.

/Kalle

What application deletes its own dlls and exes??

JD Edwards client when it updates it's business logic. It could just copy down the new business logic but for some reason the whole client reinstalls. Some sites have decided to go their own way and just copy down the business logic via another method rather than using the native facility built into the JDE client.

ORIGINAL: turbokitty

What application deletes its own dlls and exes??


Not perhaps many, but the point was more that if you do go and delete files from application installation directory (the bubble), and this is something a user could potentially do in the sudden act of stupidness when he/she finds out that Q: is accessible from within application, SoftGrid does nothing automatically to restore those hence you could "lock yourself out" from the app.

/Kalle

Actually you can try this. Go into any Softgrid delivered application and click on 'file > open'. Then browse to your Q: drive and delete some program files by right-clicking them and clicking 'delete'. You'll see that once the application window is closed and reopened, they come back.

Hmm.. so it seems. I could have sworn that not so long ago when I tested this the file stayed deleted and I had to resort to extreme repairing.

So that's avoided, but if you go through that file / open and modify your binaries (open with... to notepad, clear contents and save) then of course they are not restored since they now have been copy-on-write cached.

Yes, it's a long stretch that normal user would actually do this but application doing self-update (a big no-no with SoftGrid packages and pretty crappy idea in general especially in corporate settings) could end up with this situation.

Anyways, the OP was about security inside the bubble and that, as we have seen, is property that does not exist. So yes, breaking something is very possible inside the bubble... but depending how that something breaks also affects does it have short-term or somewhat longer-term effect to app on client. Nothing though is permanently (irrevocable) broken.

So, to reiterate - file level security is "as-is" outside the bubble, and wide open inside the bubble. That truly is the beauty of Softgrid in my opinion. Were you asking the question for any particular reason? Softgrid is handy in a locked down environment - all you do is throw whatever files you want manipulated inside the sequence to accomplish being able to change them. Softgrid keeps track of those changes and when the application is done running, everything is back to normal.