Re: What Would Deactivate Hosts File?

"CoolHandJoe" <joemagueta@xxxxxxxxx> wrote in message
news:1168116935.566612.216750@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
In my default install of Windows 2003 server the permissions on the
hosts file are

Administrators: Full Control
System: Full Control
Server Operaters: everything short of Full Control
Authenticated Users: Read & Excecute and Read
The file is owned by the administrators group.

Authenticated Users is more permissive than Users alone. Try to remove
Authenticated Users and Server Operators, reboot, and login as
administrator. HOSTS file functionality won't work.

To make it work again, add them back, reboot.

The mystery here isn't about Users versus Authenticated Users. The mystery
is why anything other than SYSTEM and Administrators would be required
against that file. I would like to understand in detail how Windows is
implementing the HOSTS file functionality. Apparently either some non
SYSTEM entity is reading that file, or alternately some of the code is
checking for permissions and refusing to work if the permissions are not set
the way it wants to see them.

--
Will



Will wrote:
I solved this problem, and I'll post how for posterity, but I would be
interested in anyone's theories about why this works. It almost looks
like
a bug or misfeature to me.

We had modified the default ACL on c:\windows\system32\drivers\etc to
exclude the Users group. If you give Users read and execute access,
and
then reboot (it will not work until you reboot), then hosts mysteriously
starts working. Note that before and after the reboot I am logged in
as
local administrator. And the folder always had Full Control access for
Administrators and SYSTEM, so it cannot be the case that giving Users
access
suddenly gave applications in my user context access, since they must
have
had read access to HOSTS before the ACL change.

What surprises me about this is that I would have thought HOSTS was
implemented in the driver or somewhere in the kernel, not in each
individual
user application. If that is the case, then why would read access to
the
Users group affect this feature, which should be implemented by a SYSTEM
entity? It's almost like the code that runs at SYSTEM level did an
ACL
check, and after it saw that Users did not have access, it bypassed the
feature. That seems like wrong behavior.

Note that the local Users group did NOT have Authenticated Users in it,
just
Domain Users.

--
Will


"Will" <westes-usc@xxxxxxxxxxxxxx> wrote in message
news:R6ydnZBeY6ceVQDYnZ2dnUVZ_oipnZ2d@xxxxxxxxxxxxxxx
On one of our Windows 2003 servers, the HOSTS file is not active. No
changes made to the c:\windows\system32\drivers\etc\hosts file are
ever
active, even after a reboot. Is there some registry setting or
group
policy that would be deactivating that feature?

--
Will





.

Relevant Pages

  • Re: \domainname.comSYSVOL is not browseable
    ... Administrators> Full Control ... Authenticated Users> Read & Execute ...
    (microsoft.public.windows.server.dns)
  • Re: SBS Standard WSUS looking for SQL
    ... Administrators - Full Control ... Authenticated Users - Read & Execute ... I changed Authenticated Users to Full Control and ##SSEE started ...
    (microsoft.public.windows.server.sbs)
  • Re: SBS Standard WSUS looking for SQL
    ... Administrators - Full Control ... Authenticated Users - Read & Execute ... I changed Authenticated Users to Full Control and ##SSEE started ...
    (microsoft.public.windows.server.sbs)
  • Re: SBS Standard WSUS looking for SQL
    ... Administrators - Full Control ... Authenticated Users - Read & Execute ... I changed Authenticated Users to Full Control and ##SSEE started ...
    (microsoft.public.windows.server.sbs)
  • Re: Restricting access on TS 2000
    ... C:\ - System & Administrators, Authenticated Users ... Authenticated Users (Read & Execute) ... >> NTFS Permissions and set this program as the session ...
    (microsoft.public.windows.terminal_services)