Macrium Support Forum

Save As window for exporting schedules not showing all folders in Documents

By Gork - 15 October 2020 2:32 PM

Just a small issue I've noticed when trying to save .sch files as exports from the Scheduled Backups tab in v7.3.5283.

If I right click on a schedule and choose export to file and click on Documents under the Quick Access section of the resulting Save As dialog box only 5 folders in my default documents special folder are shown.  There are actually about 30 sub folders in this location.  My Documents special folder isn't at the default location on the C: drive, I moved it long ago to a data drive (E:\Documents\).  The default Reflect data folder is located here, at E:\Documents\Reflect and this \Reflect subfolder does not show up in the Save As dialog box referenced herein.

However if, in the Save As dialog box, I navigate to the Documents folder by clicking on This PC, then the E: drive, then the Documents folder it properly shows all subfolders in the Documents folder, to include E:\Documents\Reflect.
By jphughan - 15 October 2020 2:37 PM

That file save dialog is a standard Windows dialog, not something specific to Reflect.  If you want to change the folders in your Quick Access list, you can do so within regular Windows Explorer, after which you should see those changes in the Save As dialog in Reflect.
By Gork - 16 October 2020 12:51 AM

The problem I'm reporting though is that the contents of the Documents folder in the Quick Access list in the Save As dialog box doesn't match the contents of the Documents folder in the Quick Access list in Windows Explorer and other Save As dialog boxes in other programs I use.

That said, I have figured out the reason for the discrepancy, and it is an annoyance having to do with being forced to run Reflect as an Administrator when, for security reasons, I do not regularly use an Administrator account in Windows 10.

When I sign into Windows I use a non Administrator account, I'll call it User here.  On User I have changed the location of the special folder Documents to point to a location other than the default location.  However, when I start Reflect, for obvious reasons, I am hit with with the UAC dialog box indicating I must provide credentials for an admin user.  I follow these instructions and input an admin user name (I'll call it AdminUser here) and password.  Due to an annoying implementation of this UAC process by MS, Reflect then runs under the AdminUser account.  Since I have only changed the location of the Documents special folder for User, the default location for AdminUser for the special Documents folder remains intact.  Because of this the Quick Access bar in the Reflect Save As dialog box points to the default location for Documents instead of the to the location the Documents folder points to for User.

I should have realized this right off the bat.  I have run into some interesting issues over the years caused by MS's implementation of UAC.  In Linux I can temporarily elevate privileges to admin for the current user to perform tasks such as running a program that requires admin access.  Windows, instead, actually runs elevated programs as the admin account user it is started from in UAC instead of elevating privileges for the current user.  It is sometimes maddening.

One reason I didn't zero in on the issue immediately is because all the names of sub folders in the Documents folder for AdminUser exist in the Documents folder for User too - there are just lots more sub folders for User in addition to these in the Documents folder for User.  So it immediately appeared to me the Documents folder location in the Reflect Save As dialog box was simply only showing part of the list of contents for Documents.

I would guess that there's no way around this problem when using Reflect and even if there was, with MS's current implementation of UAC, I don't know that altering the behavior so the Save As dialog box would show contents the logged in user would normally see instead of the user used to start Reflect would be desired anyway.  One just must keep this discrepancy in mind...  It would be helpful if the information bar for programs started as an alternate user would indicate the user name the program is running under - but this is probably a deficit on the part of MS and is nothing Macrium could/would address.
By jphughan - 16 October 2020 12:59 AM

Well you could just run as the admin user and possibly raise UAC to prompt for all elevated tasks rather than only promoting for non-Windows binaries. If a piece of malware has a privilege escalation exploit in its toolkit, then that would probably work even from a standard user account anyway, so running as admin doesn’t seem like as much of a risk to me anymore, at least not with UAC configured equivalently to what a standard user would experience. And then you’re not running the elevated process under a different account.

There actually IS some sort of API to grant elevated privileges to an account. Reflect leverages it, which is why an admin user can use Reflect to browse the System Volume Information folder, for example, which is normally locked down even from admins. But Reflect leverages some Windows capability to grant SYSTEM privileges to that account within Reflect. Don’t know of a way to do that outside of an application though, and as you say, even if that were possible, UAC works the way it works.
By Gork - 16 October 2020 1:13 AM

The biggest reason I started running daily as a non admin user is to allow me to deny access for ransomware to access specific locations in the file system.  Specifically, I save daily images from Reflect to an attached hard drive and only move said "backup" files to an unattached hard drive once per month.  If I ran an admin account regularly, malware would be able to grant access for the current user to access the location of my saved Reflect backup files.  It is just another layer of protection beyond Macrium Image Guardian.  I was hit with ransomware at one point, so I've taken extra precautions since.  (I knew I was putting myself in harm's way at the time but thought I was sandboxed in a vm but didn't have that vm properly separated from the host machine.)
By jphughan - 16 October 2020 1:26 AM

Editing permissions is an elevated task, so even running as an admin, malware wouldn’t be able to do that — unless it had a privilege escalation exploit, but then once again, that would likely work from a standard account too.
By Gork - 16 October 2020 2:50 AM

Here's what my mind process is, please correct me where I'm wrong...

If I'm logged into an admin account I can change permissions on folders at will irregardless of the ownership of the folder - UAC is not activated. My assumption, then, is that if malware was installed under an admin account it could do the same thing.

If the account I am logged into is not an admin account and said account is not the owner of the folder I am not allowed access to permissions on that folder. This leads me to believe that malware installed under a non admin account would also be denied access to permissions. 

I should say that perhaps I don't understand this which you said above: "Well you could just run as the admin user and possibly raise UAC to prompt for all elevated tasks"

Do I need to look into how to make refine UAC perhaps? I'm only privy to the slider in Windows settings that has like four positions and mine is on the seeing with the highest security. 
By jphughan - 16 October 2020 4:00 AM

The default UAC mode is to prompt for non-Windows binaries. Since permissions editing is done in Windows Explorer, admin accounts can perform those tasks without seeing a UAC prompt. But if you raise that UAC slider to the top, you will see a UAC prompt even to change permissions. (Last I checked, it also broke certain functions in the Win10 Settings app, but that was a while ago and may have been fixed.) If you want to emulate Linux even more closely, you can go into Local Security Policy and have UAC prompt for credentials even for admin users, so that you have to enter your password rather than just clicking Yes.
By Gork - 16 October 2020 4:18 AM

I understand what you're saying now, thank you. The slider was at the top and there weren't any more stringent settings that I noticed. The UAC prompt for Windows binaries might be a better choice for me, but again, I didn't see such an option.

Thanks also for the idea within the Local Security Policy. I'm not sure I'd need that if I could get UAC working for Windows binaries or even just permissions - but it's nice to know I have that option.

I'll try to figure out if I missed something in the UAC settings.
By jphughan - 16 October 2020 4:37 AM

I'm not sure how to account for your findings.  The default slider position is second from the top and says "Notify me only when apps try to make changes to my computer; don't notify me when I make changes to Windows settings."  But if you move the slider to the top, it says, "Always notify me when apps try to install software or make changes; (and when) I make changes to Windows settings."  The top slider does trigger a UAC prompt if you click the Edit button under Properties > Security.  There's even a UAC shield on that button that appears even when you have the default UAC setting, although you don't see a UAC prompt in that mode.

Are you perhaps using the built-in Administrator account as opposed to just an admin-level user?  The built-in account actually called Administrator always bypasses UAC, regardless of settings.
By Gork - 16 October 2020 6:50 AM

Nah not the built in admin account, it's one I created.

However, hypothesis... The UAC I'm seeing probably doesn't match what you're describing because I'm logged in on a non admin account. I'm at work, connected remotely and now stepped away for a lunch break so I'll check into this theory when I return.

I didn't know the built-in admin account bypasses UAC - good to know.

There is indeed another level in the UAC Settings window on the admin account which activates the option to notify for changes to Windows Settings.  I need to mess around with this a bit and see if it might work out as an easier option for me than to continue to run daily operations on a regular User account.
By Gork - 16 October 2020 12:53 PM

Ok, well...  When I started this thread I had no idea it would lead us to where it has.  However I'm glad it did - and thank you.  I've gone ahead and elevated my daily user account to an Administrator and moved the "UAC slider" up to the top.  I'm hoping the issues with the settings app won't be a problem anymore because what you have suggested will be a much more elegant way of handling my purposes moving forward.  No more running non Windows binaries as a DIFFERENT Admin user.  No more opening an elevated PowerShell in order to run system tasks such as devmgmt.msc and the like!  Ahh...