I've spent a bunch of time this morning trying to figure out how to edit my hosts file. I'm using Win 7 64 bit and I just can't open the file to write to it.

For whatever reason the file is completely locked even to the admin account. Normally, I fire up notepad as administrator and it then allows me to edit it as I wish. But now I can't even change the permissions on the file except to deny access.

I really, don't want to have to boot a custom CD in order to edit my hosts file, but that seems to be the only option that is available at this point.

I'm starting to get the feeling that the correct solution is probably going to be to format the drive and install an OS created by people that actually know what they're doing. There's no excuse for preventing the administrator of the computer from doing something like that.

EDIT: I've already tried disabling UAC and my virus software.

Try this: WinPatrol

Go to options, select view HOSTS file and edit then save. I'm not sure if it will work but I tried it once to redirect a HTTP link and it worked.

I gave it another try and apparently MS changed the behavior on the permissions so that even as administrator you can't override general user deny permissions without changing them.

I realize why they did that, but it's really irritating to find that they've changed it without giving much of a heads up.

That's weird. I'm also on Win7 64-bit (Home Premium), and just for test, I blocked "www.gog.com" using the "hosts" file with notepad. And it worked, even with my Firefox open...

My "Hosts" file is under "C:\Windows\System32\drivers\etc". Is it the same as yours?

Yep, apparently it was completely blocked by a deny all for all users. I should check my security software, I wonder if that did it. Normally, I wouldn't mind, but I'm trying out a program to block access to sites that I'm wasting too much time on, when I need to also use the internet more generally.

Removing the deny entries from users did the trick, but considering that I launch the program as admin, it shouldn't be respecting the rights given to random users when the admin account has higher privileges.

You could have just moved the file to your desktop (or any other folder), edited it there, and then moved it back.

Tried that, but all of the permissions for the users were deny. So, I couldn't even open the file to see what was in it. Also, that's a rather nasty security bug if they allow you to do that, even without write access.

I did eventually figure it out, but I'm still a bit baffled as to why the admin account no longer overrides such settings. I don't like removing the deny entries from the users group, but I do need to be able to edit the file fairly regularly as admin.

Well, that works for me with my admin account on Win 7 (64 bit). I did it a few days ago in fact.

I think I've finally got it sorted out. As far as I can tell this is just another case of Microsoft not having any idea what they're doing with regards to security.

You not only have to have permission as a user, you can't be a member of any group which is denied access and you also have to make sure that the secondary read only bit isn't set.

The first bit there is largely right, but having a separate read only bit which doesn't reflect in the files ACL is just bullshit.

The basic behavior while slightly confusing is correct. But having that additional read only bit being respected even by the admin account is kind of silly. Especially when the error message gives a completely different answer to the problem.

I'd like to ditch Windows again, but if I need service on my laptop here in China, I need to have Windows on it, and reinstalling to get service could be a huge pain.

What are you talking about?

The Windows folder is a system-wide folder, meaning you have to be an administrator or given the correct permissions to directly edit files there. When you copy the file on the desktop and edit it, you're editing it with your user's current permissions. But, when you copy back the file into the Windows folder, you're copying as an administrator. Didn't notice the shield icon on the Continue button?

In what way is security bad here?

The administrator is God, the administrator gets to do whatever the hell he or she wants to do on a computer. Permissions aren't supposed to apply to the administrator account as they just cause problems.

If as admin, I want to delete or edit a file, I should be allowed to edit or delete the file. I shouldn't have to look at other users permissions to figure out if I have permission, it should show up right there in the appropriate checkbox. I sure as hell shouldn't have to permanently change the permissions so that the admin account can edit the file. That just leaves it vulnerable to being left open.

But, more than that, being unable to delete or edit a file due to a legacy option, is bad security practice. If the files permissions on the ACL are such that a user can do anything to the file, then the person should be able to do anything to the file. Having to check in multiple places increases the likelihood of somebody accidentally leaving something writable that wasn't supposed to be.

But, more than that, this is another case of MS knows best. The admin is somebody who must be trusted and MS has never provided admin with the sort of power that root has in Linux, *BSD or *NIX in general. Having upgraded powers means having upgraded responsibility. I might need to allow an application to edit something on a case by case basis. If I have to manually change the permissions before and after it really defeats the purpose of running an application as admin.

Like I said, this is a case of MS not knowing crap about security. Any security that is sufficiently inconsistent, confusing or annoying will end up being circumvented at which point you have nothing.

I'm probably not best at explaining this, but I think this is how it works (haven't read the actual documentation, just from what I've experienced all these years in Vista / 7 / 8).

By default, all actions done by administrator accounts (note, actual user accounts set to be administrators, not the global administrator (think, root in Unix-like OSes) which has permission to do anything to anything (which is hidden / unavailable by default)), because of the UAC security feature, need to be confirmed as such, as before confirmation, they run with less-than-administrator permissions.

So, even if you are an administrator, every application that needs to do something in system-wide folders needs to be run as an administrator, because by default it is not ran with such permissions. Which is good, as enabling applications such high permissions could lead to various security and stability problems.

If you really want an account with absolute permissions, just like the root in Unix-like OSes, you could enable the hidden administrator account, but that is absolutely not recommended.

---

Anyways, right click on Notepad, run as administrator, and edit the file directly in window/system32/drivers/etc.

You definitely should not have to edit permissions and stuff to be able to edit a file with Notepad ran as an administrator, on an user administrator account. Something has messed up the permissions. What security applications are you running?

And I did all that, which is what I'm bitching about. Even after doing that, I still had to adjust permissions because it wasn't working as intended.

Inconsistent behavior of this sort is not something which I would expcect coming from a company that cares about security. I'm find having to elevate privileges in order to do something like this. What I'm not fine with is having to spend much of the morning figuring out why it isn't working as designed.