Problems w/automatic program updates

[mjdl]

Hello,
I've been using PL for some years, although with the occasional gap, such as this summer.

My problem is a long standing one with the automatic upgrade procedure, which seems to get confused and continually set off UAC elevation requests when a standard user starts PL from a Windows shortcut, rather than the login scheduled task:

1) PL is managing only the processes of a standard Windows user (i.e. the installation default),
2) the upgrade has been completed (i.e. the quick upgrade has invoked a UAC request, the user has granted it, the upgrade process terminates PL, completes the upgrade, and restarts PL, but using the elevated user context and now managing only the elevated user's processes),
3) the standard user has not logged out and logged back into their account after the PL upgrade,
4) the standard user manually closes down PL (and PL's process governor) in order to restart it in the current unprivileged user context and manage its processes. 

When all those conditions/procedures are united, then a normal, non-UAC requesting start of the updated PL is only possible by the user logging out and back in (i.e. PL autostart at login), otherwise the UAC dialog appears and the standard user starts PL in unprivileged context by cancelling  the elevation dialog.

This is the automatic update flow I'd expect to see, assuming the update invoking PL user is using PL installation defaults and PL is managing just that user's processes: the automatic quickupgrade process starts things off by requesting UAC elevation when an update is actually available (i.e. the update check is an unprivileged process), shuts down all current instances of PL processes, does the updating installation, then silently (and still in an elevated context) restarts PL in the context of the unprivileged user in such a way that no UAC dialog is presented to that unprivileged user (perhaps by explicitly running the scheduled autostart login task in the unprivileged user's context).

I think most standard users would maybe not understand that the result of an automatic PL update process is a restarted PL process that is managing *only* the processes of the elevated user context until they log out/in to restart PL in the ordinary autostart fashion, nor would most people understand that the way to get the updated PL to mange their processes without the re-login is to shut down and restart PL from the Windows shortcut while cancelling the resulting UAC elevation request.

I'm not even sure that offering automatic updating that throws up UAC elevation requests is a good usability position: far better to go with a background service that does it all hidden--although I understand that such a design would require some way of monitoring currently running PL user processes and carefully restarting them in the correct user context(s), hence be more complex.

My Windows 7 x64 (+all current updates) installation is a pretty standard one, I use the Microsoft anti-virus and EMET programs for malware protection.

[Jeremy Collake]

In the last version I changed the behavior to force elevation on update. As the updates continue, the setting will be to always run elevated. It will start at login without UAC prompts, though when manually started, you will continue to see elevation prompts. Under most scenarios, people leave Lasso running after it's auto-start, rather than manually starting it.

This will simplify a great many things, no more having to track and handle various elevation states.

[mjdl]

I just started an update via the menu, it asked for elevation, a new version of the update dialog appeared, I clicked "Update", and lo-and-behold, when the new version automatically started after the updates were applied, all the Process Lasso component processes were running in the correct unprivileged user context, not the elevated one used for the update.

So I think you've solved my problem, thank you. (The only reason I ever started PL manually was to correct the problem of the update restarting PL in an elevated context after an update.)

[BenYeeHua]

Good to hear that your issues is fixed, has a nice day.

[Jeremy Collake]

I'm not for sure it'll be resolved to your satisfaction..

As-is, the desired target is to always run elevated. That does mean you won't have to see the elevation prompt during update. You also won't see it at login. You will still see it during manual launches.

[BenYeeHua]

Yup, if it is not showing during manual launches, then you should check your UAC.

[Jeremy Collake]

For a little more clarity:

I do recognize a bug where Lasso ends up being inappropriately elevated after an update. However, with the new design being to force elevation in all cases, support for running Lasso unelevated will be deprecated.

[BenYeeHua]

So did you means after update, PL will running in Elevated rights, or it will always running in Elevated rights, except user change the setting?