Sick and tired of "cannot overwrite you do not have permission to"

I'm wondering how the permission got changed in the first place.

Permission was correct.
Permission was not correct.
Now permission is back to being correct.

cyclops said:

Have you tried just logging in as Admin?

How to do that please?

When I start my computer I just press the big blue button on the case which lights up and the machine starts. I am (I think) the Administrator (the shop who built it said so) but have never seen a pasword being needed. So perhaps I am not the Administratoe after all, which I would like to be (no-one else uses my machine).

Also, I'm not clear about the concept of Logging In. I see no opportunity to do that, just the blue button which causes a startup (as above).

EDIT: I have come across this image, showing I am the Administrator.

My main question however is how to understand logging on.

Layback Bear said:

I'm wondering how the permission got changed in the first place.

Permission was correct.
Permission was not correct.
Now permission is back to being correct.

The permissions (and ownership) on the files are correct. The permissions were correctly set by the operating system during the installation of the various apps. Nothing has changed the permissions (yet).

The problem is, some apps still cling to using INI files (or other configuration files) that they place in the Program Files folder. Putting those type of files in that protected folder structure is not a good idea for Windows 7. It was not a good idea for XP or Vista either. My screenshot in post #4 shows an INI file for UltraVNC. If I want to edit that file, I can either use the tool that UltraVNC provides or open the INI in a text editor that is running as admin. It gets rather annoying to navigate to these types of files via Notepad's File > Open dialog box. The OP would rather use Windows (file) Explorer and just double click to open/edit files like this.

One solution is to make a shortcut file with a target like this...

Code:

%windir%\system32\notepad.exe "C:\Program Files\uvnc bvba\UltraVNC\UltraVNC.ini"

...then change the properties of that shortcut to run as admin. A user would need to make a shortcut like that for each configuration file of interest. The user would still need to deal with the UAC, but the native Windows file protection scheme would remain intact. And that is a good thing

This might work too:
Elevated Program Shortcut without UAC Prompt - Create
I have not tired it.


Edit: in the info above and the info below, I intentionally left out the discussion about access tokens. However, this makes it sound like the the primary reason for the editor cannot write to a protected file is the editor's integrity level. The normal process for assigning the needed access token to the editor will raise the editor's integrity level to high. You can watch this via Process Explorer.

Stevekir said:

cyclops said:

Have you tried just logging in as Admin?

How to do that please?
~~~

Logging in as admin is of little value in this situation. Apps (like notepad) that you start while logged on as admin (administrator) should still run at the normal Medium Integrity level. That integrity level is not enough to edit the protected files that we are discussing. The text editor needs to be running at the High Integrity level (run as admin) to be able to edit these files - or - you have to lower the protection level of these files (bad idea).

By default, Windows (file) Explorer runs at the Medium Integrity level. If you use the Windows (file) Explorer to navigate to a text file and then double on that text file, notepad should start at the Medium Integrity level. Some noteworthy exceptions to that norm are web browsers like IE and Chrome. Both of those start at the Medium Integrity level, but then they start other copies of themselves at lower Integrity levels. Those lower copies show you the websites. The lower the Integrity level, the fewer things that the browser can infect.

Your Desktop and Taskbar are presented to you by the Windows (file) Explorer running at the Medium Integrity level. Double clicking on a normal shortcut (icon) on the Desktop or Taskbar is just like the info presented in the paragraph above.

The bad guys are always finding ways to make browsers and/or PDF readers escape those lower Integrity levels. That is called privilege escalation.


If anyone is still awake at this point, the shortcut methods mentioned above are the safest solution to the OP's issue. The next safest thing is to add your user account to the NTFS permissions. You only need Write permissions. You do not need Full Control. And you should only change the file(s) of interest. Don't change the permissions on the entire app folder... and certainly don't change the permissions on the entire Program Files folder.

Or - you could throw all caution to the wind and turn off the UAC. Doing that lets most everything run at the High Integrity level - including infections. [There are security apps that can be used instead of the UAC.]


While I'm putting people to sleep with this topic, I'll go ahead and mention the VirtualStore folder. If an app that is running at the Medium Integrity level needs to write to an INI file in the a protected folder structure. Windows 7 might try to help you out by placing a copy of that INI file into the VirtualStore folder. I wasted a lot of labor before I figured that out. In my case, the INI file was in the Windows folder and the VirtualStore folder. The two copies contained different info. I could not tell the old app to look for the INI file in another place. [Yes, I know about hard and symbolic links. That was not the best solution in this case.]

One final point: If computer #1 is connected to computer #2 via the admin share (C$), then changes to the protected files on computer #2 can be made from computer #1 without any UAC prompts. Infections on computer #1 can do a lot of damage to computer #2.

Blackmagic12345 said:

@pyprohly, thanks a mil. You just saved me a million headaches

Enjoy.

Layback Bear said:

I'm wondering how the permission got changed in the first place.

Permission was correct.
Permission was not correct.
Now permission is back to being correct.

No permissions were changed. Blackmagic states that his problem file resides under the 'Program Files' folder, and it would make sense that editing anything in there must require UAC's approval.


@Stevekir Please start a new thread for your unrelated question.

UsernameIssues said:

I'm not smarter than the Operating System

Yes you are. It'll be some time before computers become more intelligent than a brain.

UsernameIssues said:

If the user is a member of the builtin:administrators group, then why must the ownership and NTFS permissions be changed [...] to make changes to the file?

[IMG]

I see no need to change the file's ownership. Adding/Giving my user account NTFS write permissions is enough.

I think you know why the NTFS permissions had to be changed—that was the cause of OP’s problem—but the taking ownership part, on the other hand, I’m glad you questioned that because taking ownership is indeed hardly necessary in Blackmagic's case.

As per the intention, the registry tweak I've attached is only a parody of Brink’s, so I kept most bytes the same. By keeping the file as similar to the original as possible, its functionality will be familiar to those who are familiar with Brink’s file. I didn't bother pulling out the Takeown command in concern that the resulting file will differ too much from the original. And modifying the file as less as possible saves me the effort too.

Also, if I were to keep posting back and forth to Blackmagic and eventually establish some set of instructions he should perform to fix his issue, it may only be relevant to that file/folder of his, and he probably wants the process done to multiple items. Providing the registry tweak with Takeown not only saves time on my behalf, but also the OP’s, all while maintain a high success rate.