Text 18814, 203 rader
Skriven 2007-06-16 11:01:06 av Rich (1:379/45)
Kommentar till text 18813 av Rich Gauszka (1:379/45)
Ärende: Re: INFCACHE.1
======================
From: "Rich" <@>
This is a multi-part message in MIME format.
------=_NextPart_000_0173_01C7B005.A3B01720
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
"UAC and other file system protection mechanisms in Vista were =
supposed to eliminate this issue altogether by making INFCACHE.1 a = protected
OS file."
This is bull. The file is more protected that it was in Windows XP. = For
example, Imn Windows Vista administrators have the same limited read = access
as non-admins. This means UAC or elevation makes no difference. = Now maybe
the "other file system protection mechanisms" to which this = refers is the
updated ACL which allows write access only to the system = account. The system
account can do as it wishes.
The article has other silly points. It links to someone writing =
about the KB article http://support.microsoft.com/kb/KB934637 though not =
directly to this. This article does describe an issue with potential = INF
corruption but only on non-English systems and so far noted only on = Swedish
and Finnish. Furthermore, it has nothing to do with developers =
exploiting privilege or anything else. It's a simple bug.
Rich
"Rich Gauszka" <gauszka@dontspamhotmail.com> wrote in message =
news:467417b1$1@w3.nls.net...
didn't count on developers exploiting elevated privelege? Five years =
to=20
ship and 10,000 people to develop and no one figured that out?
from the same link -
Furthermore, UAC and other file system protection mechanisms in Vista =
were=20
supposed to eliminate this issue altogether by making INFCACHE.1 a =
protected=20
OS file. However, what they didn't count on was developers exploiting =
the=20
elevated privilege level of their installer routines to bypass those =
file=20
protections - a scenario they nwo realize they need to correct for by=20
replicating the functionality that was "retired" with XP (but that =
needs to=20
be rewritten from scratch for Vista - hence the delay in the service =
pack=20
delivery).
"Mike N." <mike@u-spam-u-die.net> wrote in message=20
news:6j1873hom1vdfbdtfjlakum5hegrkn9lmr@4ax.com...
>
> =
http://weblog.infoworld.com/enterprisedesktop/archives/2007/06/vistas_wea=
k_lin.html
>
> "There's a weak link lurking under the covers of Windows Vista. It's =
the
> collection of ".inf" and related hardware "setup" files collectively
> referred to as the Windows Device Driver Store
> ...
> After an hour or so of playing "find the driver" with Windows I =
resigned
> myself to having to reinstall the OS, which for me meant 2-3 days of
> tweaking, tuning and application installing just to get back to a
> reasonably functional level."
>
> "Corruption of the Driver Store by 3rd party installers is a known =
issue
> and one they plan to address by reviving a mechanism from Windows XP =
that
> automatically regenerates the indices if/when they're corrupted.
> Apparently, this particular bit of code was "prematurely retired" =
with
> Vista, a decision I think Microsoft is now regretting. In the =
meantime"
>
> Wow - watch those drivers!=20
------=_NextPart_000_0173_01C7B005.A3B01720
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3Diso-8859-1>
<META content=3D"MSHTML 6.00.6000.16481" name=3DGENERATOR></HEAD>
<BODY id=3DMailContainerBody=20
style=3D"PADDING-RIGHT: 10px; PADDING-LEFT: 10px; FONT-SIZE: 10pt; = COLOR:
#000000; PADDING-TOP: 15px; FONT-FAMILY: Arial"=20 bgColor=3D#ffffff
leftMargin=3D0 topMargin=3D0 CanvasTabStop=3D"true" = acc_role=3D"text"=20
name=3D"Compose message area">
<DIV> "UAC and other file system protection mechanisms in =
Vista were=20
supposed to eliminate this issue altogether by making INFCACHE.1 a = protected
OS=20
file."</DIV>
<DIV> </DIV>
<DIV>This is bull. The file is more protected that it was in =
Windows=20
XP. For example, Imn Windows Vista administrators have the same =
limited=20
read access as non-admins. This means UAC or elevation makes = no=20
difference. Now maybe the "other file system protection = mechanisms"
to=20
which this refers is the updated ACL which allows write access only = to
the=20
system account. The system account can do as it wishes.</DIV>
<DIV> </DIV>
<DIV> The article has other silly points. It links to =
someone=20
writing about the KB article <A =
title=3Dhttp://support.microsoft.com/kb/KB934637=20
href=3D"http://support.microsoft.com/kb/KB934637">http://support.microsof=
t.com/kb/KB934637</A> though=20
not directly to this. This article does describe an issue with =
potential=20
INF corruption but only on non-English systems and so far noted only on =
Swedish=20
and Finnish. Furthermore, it has nothing to do with = developers=20
exploiting privilege or anything else. It's a simple bug.</DIV>
<DIV> </DIV>
<DIV>Rich</DIV>
<DIV> </DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Rich Gauszka" <<A title=3Dmailto:gauszka@dontspamhotmail.com=20
=
href=3D"mailto:gauszka@dontspamhotmail.com">gauszka@dontspamhotmail.com</=
A>>=20
wrote in message <A title=3Dnews:467417b1$1@w3.nls.net=20
=
href=3D"news:467417b1$1@w3.nls.net">news:467417b1$1@w3.nls.net</A>...</DI=
V>didn't=20
count on developers exploiting elevated privelege? Five years to =
<BR>ship and 10,000 people to develop and no one figured that =
out?<BR><BR>from=20
the same link -<BR>Furthermore, UAC and other file system protection=20
mechanisms in Vista were <BR>supposed to eliminate this issue =
altogether by=20
making INFCACHE.1 a protected <BR>OS file. However, what they didn't =
count on=20
was developers exploiting the <BR>elevated privilege level of their =
installer=20
routines to bypass those file <BR>protections - a scenario they nwo =
realize=20
they need to correct for by <BR>replicating the functionality that was =
"retired" with XP (but that needs to <BR>be rewritten from scratch for =
Vista -=20
hence the delay in the service pack <BR>delivery).<BR><BR><BR>"Mike =
N." <<A=20
title=3Dmailto:mike@u-spam-u-die.net=20
href=3D"mailto:mike@u-spam-u-die.net">mike@u-spam-u-die.net</A>> =
wrote in=20
message <BR><A title=3Dnews:6j1873hom1vdfbdtfjlakum5hegrkn9lmr@4ax.com =
=
href=3D"news:6j1873hom1vdfbdtfjlakum5hegrkn9lmr@4ax.com">news:6j1873hom1v=
dfbdtfjlakum5hegrkn9lmr@4ax.com</A>...<BR>><BR>>=20
<A=20
=
title=3Dhttp://weblog.infoworld.com/enterprisedesktop/archives/2007/06/vi=
stas_weak_lin.html=20
=
href=3D"http://weblog.infoworld.com/enterprisedesktop/archives/2007/06/vi=
stas_weak_lin.html">http://weblog.infoworld.com/enterprisedesktop/archive=
s/2007/06/vistas_weak_lin.html</A><BR>><BR>>=20
"There's a weak link lurking under the covers of Windows Vista. It's=20
the<BR>> collection of ".inf" and related hardware "setup" files=20
collectively<BR>> referred to as the Windows Device Driver =
Store<BR>>=20
...<BR>> After an hour or so of playing "find the driver" with =
Windows I=20
resigned<BR>> myself to having to reinstall the OS, which for me =
meant 2-3=20
days of<BR>> tweaking, tuning and application installing just to =
get back=20
to a<BR>> reasonably functional level."<BR>><BR>> "Corruption =
of the=20
Driver Store by 3rd party installers is a known issue<BR>> and one =
they=20
plan to address by reviving a mechanism from Windows XP that<BR>>=20
automatically regenerates the indices if/when they're =
corrupted.<BR>>=20
Apparently, this particular bit of code was "prematurely retired" =
with<BR>>=20
Vista, a decision I think Microsoft is now regretting. In the=20
meantime"<BR>><BR>> Wow - watch those drivers!=20
<BR><BR></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0173_01C7B005.A3B01720--
--- BBBS/NT v4.01 Flag-5
* Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45)
|