PL's Task scheduler logon tasks not working

[mjdl]

Hello,
Just installed and activated PL Pro x64 4.00.24 on Windows 7 x64. I chose the default configuration: PL launched via the Task Scheduler. I was logged on as a Limited user during installation, the PL installer asked for elevation and was elevated. The Task scheduler entries were present, with the task starting with "Highest Privileges" in the "Administrators" group.

To verify that installation had succeeded, I rebooted my notebook and logged back into my usual limited account, but there was no sign of either the PL governor or UI process. Attempting to run manually either the PL governor task or the UI task via the task scheduler did not work either.

To verify that the install helper was working correctly, I started PL GUI manually (in limited user context), reran it and when it was elevated, I deselected "Highest privileges", and exited PL (governor and GUI). It had correctly set up the HKLM Run entries for the governor and GUI to run in the user context, but didn't delete the task scheduler tasks. I deleted these manually, and then reran the PL GUI, this time reenabling the "Highest Priviliges". PL deleted the HKLM Run entries and recreated the Task Scheduler entries, which failed to work as before, when I logged back in.

So at the moment I'm running PL via the HKLM entries in the limited user context, which is how I've always run it in the past, before I upgraded my notebook to Windows 7 x64 from x32 (and PL from 3.x.x.x x32 to PL 4.x.x.x x64). It works very nicely, but I'd like to figure out what's stopping the Task Scheduler entries from working correctly.

In the past, on Vista and Windows 7 x32, I've used Task Scheduler to start programs with "Highest Privileges", but the execution context user specified in the task properties has always been a user in the "Administrators" group, not the "Administrators" group itself. Just as an experiment, I specified "NT AUTHORITY/SYSTEM" as the user context in the task and then both tasks did start on limited user login and within SYSTEM context, but there was no GUI access; I think it was probably running entirely separate in another session or desktop (I forgot to check with Process Explorer) than the interactive user (at least I hope so, from a security perspective--think "shatter attack"!). I wish I knew more about how Windows manages security contexts to understand why the PL login tasks are not working when i) a limited user logs in and ii) the task attempts to execute in a privileged group, rather than user, context.

[Jeremy Collake]

Thanks much for reporting this. I believe it is related to the limited/standard user, and more specifically the group(s) they/you belong to. The idea at the time of development was that no non-Administrative user would be starting PL with elevated rights. This was a bad assumption as the limited user might still want to see his or her own elevated processes. The reason for the failure to auto-start the task, or to manually start it, is because the user is not a member of the administrators group. This is the mistake I made.

The failure to later (from the GUI) *delete* the scheduler tasks is also due to the limited user, most likely. I am investigating.

[Jeremy Collake]

I have now uploaded a 'test' build at the beta URLs.

It uses the 'Users' group, so should be good. I have some concern about it being overly inclusive, if anything. Some specialized users get created by some applications.

As for the task scheduler using a specific user, as you suggest, it is done when you tell PL to only log-in for you (and not all users). It should be anyway ;o. I am retesting it all to be sure.

[Jeremy Collake]

Actual testing of the .25 beta I threw out the other day revealed that the Task Manager will not allow proper starting of Process Lasso with this new task configuration. I will continue to look into this and when I've got a solution that is well tested, I will report back.

[mjdl]

Jeremy, thanks for your work on this; I haven't actually had a chance to try the beta build you made. I will wait for any further developments, as PL works nicely when run in via the HKLM/HKCU auto-runs, and in any case I have no quibbles about the quality of the software.

Running as a limited user is pretty much the only way I use my notebook, I depend on programs to do the UAC samba correctly if they need elevation, and if they can't, then starting them via an Administrator command prompt works.

But I still don't know enough about Windows security to be really helpful. In particular, it strikes me as strange that Windows would ever allow a privileged elevated task to be created (by a privileged, elevated install program) on behalf of, and with the primary identity & privileges, of a limited user but with temporary elevated privileges: surely the "highest privileges" of a user are always limited by group membership--that's the whole point! Higher privileges than that should require a change in the primary identity.

I'll have to do some reading and sort these confusions out.

[Jeremy Collake]

I am happy to report that (afaik) this has been properly fixed in the just released v4.00.25 (#87800). My testing shows as much. It was a simple switch from the Administrators group to the Users group. I am thankful you caught this, and sad I didn't fix it earlier. I did need to properly test it though. My earlier tests were flawed in some way. I knew they had to be, it made no sense (as you pointed out).

This build rolls out a few good fixes and improvements. One of them is per-machine instance count limits, to allow for easy license compliance (of other applications with restrictive EULAs). I was told the EULAs of many applications mandate administrators buy more copies than they need. Now Process Lasso can make sure you don't go over quota (once properly configured). An instance of the core engine must be running with rights and setup to manage all users for the feature to work.

I believe this is a good build. My confidence has been low lately, but I really took the time and reviewed the changes carefully.

[mjdl]

I won't have a chance to test this until some time in the 2nd week of January, but I'll post an update when I do try it.

UPDATE: On past experience, Jeremy's worries about his fixes usually means that the fixes have solved the problem

[Jeremy Collake]

I can say it has worked in all my tests, so should be good . I've also heard no complaints. I'm pretty confident (famous last words).