SoftGrid 4.5 Sequencer observations / questions
While reading the SoftGridReadme.htm, I was excited to read that the Local Interaction Policy was added to the Sequencer OSD tab for use, so I decided to install (not upgrade) the beta Sequencer for testing. Here are some observations trying to get to that point:
-
The Sequencer MSI installation file failed because Virtual C++ 2005 redistributable package wasn't installed.
-
WORKAROUND: The Virtual C++ 2005 redistributable package is included in the EXE packaged file.
-
-
Sequencer shortcuts from previous installation don't work & have to re-associate with different install path for new version (no longer c:\program files\softricity\... – now it’s c:\program files\microsoft softgrid\...).
-
WORKAROUND: User will be prompted to Fix or Delete shortcut
-
-
Opening a package for upgrade was unsuccessful. Sequencer decodes package to original locations, but eventually stops at ‘Applying security descriptor to file:..’.
-
What is this ‘Applying security descriptor to file:’?
-
What is this trying to do? It's not part of the previous sequencer software.
-
This is all I've got for now, because I couldn't successfully open a package for upgrade.
-
Answers
- Found the answer - I added TRUE to the Element Text field in the bottom right pane, save the package, & validated that the Local Interaction Policy was included properly. Everything looks great.
All Replies
badshadd wrote: Opening a package for upgrade was unsuccessful. Sequencer decodes package to original locations, but eventually stops at ‘Applying security descriptor to file:..’. Oops - I stand corrected. After sitting for 30 minutes at the above mentioned screen, the Sequencer finally opened. The manually entered Local Interaction Policy that had been in the OSD file was removed, but I was able to add POLICIES & LOCAL_INTERACTION_ALLOWED elements. Now all I have to figure out is how to add the TRUE attribute / value - that isn't available.
Anyone have any guidance on this one?
badshadd wrote: -
What is this ‘Applying security descriptor to file:’?
-
What is this trying to do? It's not part of the previous sequencer software.
I'm still interested in having these questions answered as well.
-
- Found the answer - I added TRUE to the Element Text field in the bottom right pane, save the package, & validated that the Local Interaction Policy was included properly. Everything looks great.
badshadd wrote:
-
What is this ‘Applying security descriptor to file:’?
-
What is this trying to do? It's not part of the previous sequencer software.
The virtual environement never used to handle ACLs. With 4.5 Sequences, you now have security descriptors for files (but not registry). Is this the same as NTFS ACLs? We need time to play with these to see what we can do, but presumably we can now make pkg files read-only so that the user cannot upgrade them (even if they went into the user personalization pkg file).
So for example, an app that has a "check the web for updates" button would be useless. But the user can still try the update and unless you do a good job locking down the files they might get a half upgrade. But this is part of why we have such a long beta so we can figure these things out before Microsoft releases it to the masses.
-
Tim Mangan wrote: With 4.5 Sequences, you now have security descriptors for files (but not registry). Is this the same as NTFS ACLs?
Yes it is, based on my recent observations (my SFT Explorer will be able to show ACLs to files/dirs inside package in updated version available very soon now) Sequencer stores NTFS ACLs to the files/directories contained in the package (note that this behaviour can be switched off from Sequencer Options). Caveat emptor: This probably has no direct bearing on securing the .pkg file as you would need to analyze very throughly which files need protection from user mangling. By default it seems that 4.5 Sequncer sets ACLs to at least to osguard.cp file specifically, preventing user updating.
/Kalle
Tim Mangan wrote: So for example, an app that has a "check the web for updates" button would be useless. But the user can still try the update and unless you do a good job locking down the files they might get a half upgrade. But this is part of why we have such a long beta so we can figure these things out before Microsoft releases it to the masses.
It has always been my experience that if a user does not log in with elevated rights to the local workstation, IE with a user account that is a member of the local administrator's group, then they can't update any virtualized application. There are only two ways I've seen a user be able to update a virtualized app. One, if they have local administrative rights, and two, if you grant the process elevated rights when it runs using a GPO, script, etc.
Is that not the expected behaviour?
