[To be retested] Muti user mode probably won't work anymore

[wokhan]

Following latest moves for an "always running" Notifier.exe process for the current user, I'm afraid it broke two things:

• when another user's session was open and a connection was blocked, the owning session was the one receiving the notification. This is why Notifier was run as SYSTEM with an important work around impersonation: so that it was able to impersonate whichever user was having an open session.
• from there, the RuleManager separated process allowed to trigger UAC since notifications are not solely for admins (i.e. you can get a notification while not being an admin and ask for someone around to add an exception to the firewall - or block completely following attempts).

@harrwiss, were you aware of those functionalities (which were not actually advertised)?

[harrwiss]

Hi @wokhan, sorry when I broke something I was not aware of. It's sometimes difficult to know what the purpose/history of some code was and often it's better to do some cleanup instead of trying to fix it without knowing how to test it's function.

However, I'm still not sure what the actual use case would be and how to reproduce it:

when another user's session was open and a connection was blocked, the owning session was the one receiving the notification.

Q: How do you open another users session? With switch user?

In this case I think with the new Notfier it would NOT be a problem anymore, because Notifier is not triggered by an event from windows eventlog and can (in theory though) run in 2 diff. user sessions independent i.e. each one can receive notifications - would have to be tested without admin rights probably 🤔

Q: Is the "always run as admin" option related to this?

[wokhan]

Hi @harrwiss, no problem I should have "detected" this in the corresponding PR and it shouldn't be an issue for 90% of our users... (a few of them only are probably on the nightlies anyway, so even less impacting...).

A: Indeed, you can have multiple sessions with the "switch user" feature, but you can also with remote desktop.
The issues I see here are:

1. User B would get a notification even if the connection was blocked in user A's session (which wouldn't make sense :-) ) - but this can be fixed easily;
2. Notification would also only work for admins (since only an admin can set up Notifier and since it runs under current user's identity - and since security log can only be used by said admins - didn't check that one but would be expected for a security log ;-) ).

B: the "always run as admin" was here to always launch the Console itself as admin (when I allowed standard users to partly use it as well). That way power users wouldn't have to ask for admin mode everytime through the corresponding buttons (on corresponding screens).