Link to home
Start Free TrialLog in
Avatar of 12string
12string

asked on

cant write to Windows hosts file

Hello EE,

I am signed in as a local admin on a windows 7 computer.  I am not signed as THE local admin though.  I am trying to update the hosts file for accessing other websites from another domain.  This is working on other computers currently that I have adjusted for these websites.  if I log on as THE local admin I can make the change.  If I logon as one of the other local admin accounts that are part of the local administrators group it doesnt work.  I have even gone as far as putting one of the local admin accounts as owner of the hosts file and yet when logged on as that account still can not make change to hosts file.  what can i do to correct this problem?  Thanks for your help!
ASKER CERTIFIED SOLUTION
Avatar of Mahesh
Mahesh
Flag of India image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
By default, everything in %windir% and deeper is owned by "TrustedInstaller"

Take Ownership of the %windir%\System32\etc\drivers\etc folder, then give the new owner (I suggest giving ownership to the Administrators group) Full Control on the Permissions tab.User generated image
THEN running notepad as administrator will be able to save changes there.
Avatar of 12string
12string

ASKER

Thank you MaheshPM that is another option but how do I change that back so that one doesnt have to do that step?  if the account is in local administrators and local admins have that ability then why does this happen?
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Thank you Mahesh I was wondering whether I would have to use gpedit but didnt want to waste the time looking the exact location.

Also Thanks Darr247 I did do that as well, before I came to EE, but still got same problem.  took ownership using a specific local acct and then logged on as that acct.
Let me add something about the stuff behind this "effect".
First: UAC introduced these type of effects and UAC came with vista. How come that after 7 years, this problem is still not fully understood by anyone? :))

1. You are logged in as some admin, not as the account "administrator". With default settings, the UAC is off for the account "administrator" even when it's on for the rest. That's why it works with the admin called “administrator” and not with any others.

2. If, as in this case, the ACL of a file does hold the group "administrators" with at least change permissions and NOT everyone AND NOT authenticated users [and not your own account] - then you CANNOT modify the file EVEN when you are a member of the admins group. [By the way: the ownership does not matter]
Why is that so? Because of the UAC. The UAC introduced the concept of elevation [see 3.]. Without "elevating", members of the admin group are treated as weak, restricted users. From the perspective of the ACL, they don't even belong to the group administrators!

3.How to elevate? Now for the most important part...
The host file is usually opened with notepad. Microsoft, in their enormous generosity, has been providing this square and simple program for ages. Problem: it is NOT UAC-aware! It won't TRIGGER elevation. The process of elevating (after "dimming the screen") would need you to click ok on a dialogue that asks for consent, that's all. But notepad is too simple to provide that :) It has not been made compatible with MS’ own technology. Too bad. By the way: task manager is another program that misses to trigger elevation under some circumstances. Poor work.
What can we do? We can…
-modify the ACL of the file to simply hold hold our own account name! or…
-elevate the viewer (notepad) manually by right clicking notepad.exe and selecting “run as administrator”. Or…
-use runas on notepad providing the credentials of the “real” administrator. Or…
-save the file somewhere else and later, push it over to its final destination using explorer! Explorer is UAC aware and will trigger elevation while we move that file and overwrite the old one.
Turning off UAC is not the way to go, believe me.

4. There is even more to it: there is a little known security feature called “mandatory integrity controls/levels” (“MIC”/”MIL”) that can also cross your plans! Think of it as some kind of extra security layer next to the NTFS ACL. If some files/folders are set to have an MIL of “high”, then only elevated processes may write to it. Writing to the root of c:\ is such an example, too.
ILs can be read out and modified by tools like chml.exe

Spread the word
Thanks McKnife for the explanation.  To answer your question:

<How come that after 7 years, this problem is still not fully understood by anyone?>

My customers were more win xp than win vista, there was very little need to know or work with win vista ergo the need to ask why this problem exists.

Thanks for the insight and yes I will pass the info on, I know quite a few people will be interested in this answer