<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://blogs.msdn.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Fixing "LUA Bugs", Part II</title><link>http://blogs.msdn.com/b/aaron_margosis/archive/2006/03/27/fixing-lua-bugs-part-ii.aspx</link><description>A systematic approach for working around LUA bugs that avoids unnecessary exposure - "the rest of the story"</description><dc:language>en-US</dc:language><generator>Telligent Evolution Platform Developer Build (Build: 5.6.50428.7875)</generator><item><title>re: Fixing "LUA Bugs", Part II</title><link>http://blogs.msdn.com/b/aaron_margosis/archive/2006/03/27/fixing-lua-bugs-part-ii.aspx#5600635</link><pubDate>Mon, 22 Oct 2007 17:34:16 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:5600635</guid><dc:creator>PJ</dc:creator><description>&lt;P&gt;thanks for these informations.&lt;/P&gt;
&lt;P&gt;Reading this article i search for explanation why 'cocreateinstance' may fail when UAC is On...I did'nt find it.&lt;/P&gt;
&lt;P&gt;did you have some ideas?&lt;/P&gt;
&lt;DIV class=ajmReply&gt;
&lt;P&gt;&lt;EM&gt;[Aaron Margosis]&amp;nbsp; Most likely it's because the component you're trying to instantiate is doing something that requires admin- or admin-like permissions.&amp;nbsp; Another possibility is that if you are running elevated and try to instantiate something that is registered in HKCU\software\classes, COM ignores that hive when the caller is running elevated.&lt;/EM&gt;&lt;/P&gt;&lt;/DIV&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;&lt;img src="http://blogs.msdn.com/aggbug.aspx?PostID=5600635" width="1" height="1"&gt;</description></item><item><title>Changing access control on folders vs. files</title><link>http://blogs.msdn.com/b/aaron_margosis/archive/2006/03/27/fixing-lua-bugs-part-ii.aspx#1686593</link><pubDate>Fri, 16 Feb 2007 05:14:36 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:1686593</guid><dc:creator>Aaron Margosis' WebLog</dc:creator><description>&lt;p&gt;More info on the risks of changing access control lists to fix LUA bugs.&lt;/p&gt;
&lt;img src="http://blogs.msdn.com/aggbug.aspx?PostID=1686593" width="1" height="1"&gt;</description></item><item><title>re: Fixing "LUA Bugs", Part II</title><link>http://blogs.msdn.com/b/aaron_margosis/archive/2006/03/27/fixing-lua-bugs-part-ii.aspx#773599</link><pubDate>Wed, 27 Sep 2006 15:20:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:773599</guid><dc:creator>Doug Deden</dc:creator><description>Permutor - &lt;br&gt;&lt;br&gt;The Student Edition of Office 2003 did the same thing to me. The problem was access rights to a part of the Program Files\Common Files directory structure. I think it was MSOCache, which Office uses to install parts as needed. Even though I did a full install as admin, apparently limited users still needed to see MSOCache. I think I just gave them read-rights, but I don't have that PC handy.&lt;div style="clear:both;"&gt;&lt;/div&gt;&lt;img src="http://blogs.msdn.com/aggbug.aspx?PostID=773599" width="1" height="1"&gt;</description></item><item><title>Changed permissions on your %windir%</title><link>http://blogs.msdn.com/b/aaron_margosis/archive/2006/03/27/fixing-lua-bugs-part-ii.aspx#742286</link><pubDate>Wed, 06 Sep 2006 08:39:49 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:742286</guid><dc:creator>The things that are better left unspoken</dc:creator><description>On the second Tuesday of the month Microsoft introduces updates for it&amp;amp;amp;#39;s products. As a system administrator&lt;img src="http://blogs.msdn.com/aggbug.aspx?PostID=742286" width="1" height="1"&gt;</description></item><item><title>Changing permissions on your %windir%</title><link>http://blogs.msdn.com/b/aaron_margosis/archive/2006/03/27/fixing-lua-bugs-part-ii.aspx#741574</link><pubDate>Tue, 05 Sep 2006 23:14:56 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:741574</guid><dc:creator>The things that are better left unspoken</dc:creator><description>One way of coping with the challenges corresponding with &amp;amp;quot;the principle of least administrative privilege&amp;amp;quot;&lt;img src="http://blogs.msdn.com/aggbug.aspx?PostID=741574" width="1" height="1"&gt;</description></item><item><title>LUA Buglight public [pre]-release</title><link>http://blogs.msdn.com/b/aaron_margosis/archive/2006/03/27/fixing-lua-bugs-part-ii.aspx#691414</link><pubDate>Tue, 08 Aug 2006 00:01:08 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:691414</guid><dc:creator>Aaron Margosis' WebLog</dc:creator><description>&amp;amp;quot;Why does Application XYZ need to run as admin?&amp;amp;quot;&lt;img src="http://blogs.msdn.com/aggbug.aspx?PostID=691414" width="1" height="1"&gt;</description></item><item><title>re: Fixing "LUA Bugs", Part II</title><link>http://blogs.msdn.com/b/aaron_margosis/archive/2006/03/27/fixing-lua-bugs-part-ii.aspx#680582</link><pubDate>Thu, 27 Jul 2006 22:38:10 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:680582</guid><dc:creator>jjudeb</dc:creator><description>We're experiencing the same problem as Permutor, installing MSOffice 2003 Professional on a Citrix server. &amp;nbsp;Everything works fine for Administrator, but not for limited user. &amp;nbsp;Since Citrix Published Applications run under Anonymous user accounts, MSOffice cannot be used as a published application any more. &amp;nbsp;Everything worked fine for years with MSOffice XP, but it's hosed with MSOffice 2003.&lt;div style="clear:both;"&gt;&lt;/div&gt;&lt;img src="http://blogs.msdn.com/aggbug.aspx?PostID=680582" width="1" height="1"&gt;</description></item><item><title>re: Fixing "LUA Bugs", Part II</title><link>http://blogs.msdn.com/b/aaron_margosis/archive/2006/03/27/fixing-lua-bugs-part-ii.aspx#667732</link><pubDate>Mon, 17 Jul 2006 02:39:18 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:667732</guid><dc:creator>John Bokma</dc:creator><description>Hi Aaron,&lt;br&gt;&lt;br&gt;Contacting the developer of a program in order to report a LUA bug might be a huge PITA. I did twice, and on both accounts the developers came up with wonderful stories why the application misbehaved. See: &lt;br&gt;&lt;br&gt;&lt;a rel="nofollow" target="_new" href="http://johnbokma.com/mexit/2005/11/09/irfanview-ini-fix.html"&gt;http://johnbokma.com/mexit/2005/11/09/irfanview-ini-fix.html&lt;/a&gt;&lt;br&gt;&lt;br&gt;and&lt;br&gt;&lt;br&gt;&lt;a rel="nofollow" target="_new" href="http://johnbokma.com/mexit/2006/07/14/launchy-lua-bug.html"&gt;http://johnbokma.com/mexit/2006/07/14/launchy-lua-bug.html&lt;/a&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;&lt;img src="http://blogs.msdn.com/aggbug.aspx?PostID=667732" width="1" height="1"&gt;</description></item><item><title>Changing access control on folders vs. files</title><link>http://blogs.msdn.com/b/aaron_margosis/archive/2006/03/27/fixing-lua-bugs-part-ii.aspx#638151</link><pubDate>Tue, 20 Jun 2006 05:16:42 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:638151</guid><dc:creator>Aaron Margosis' WebLog</dc:creator><description>More info on the risks of changing access control lists to fix LUA bugs.&lt;img src="http://blogs.msdn.com/aggbug.aspx?PostID=638151" width="1" height="1"&gt;</description></item><item><title>re: Fixing "LUA Bugs", Part II</title><link>http://blogs.msdn.com/b/aaron_margosis/archive/2006/03/27/fixing-lua-bugs-part-ii.aspx#593746</link><pubDate>Tue, 09 May 2006 19:44:13 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:593746</guid><dc:creator>Aaron Margosis</dc:creator><description>AC - no, I'm not saying that users shouldn't be able to - I'm just pointing out some caveats:&lt;br&gt;&lt;br&gt;1) Many applications won't install correctly even to a folder the user can write to, because the installation may try to register COM/DCOM components (writing to HKCR) or write other configuration data to HKLM, etc.&lt;br&gt;&lt;br&gt;2) Many organizations do not want end users installing unauthorized programs due to legal, licensing, security or compliance issues.&lt;br&gt;&lt;br&gt;3) As I mentioned before, binaries that the user can write to increases attack surface - at least for that user.&lt;div style="clear:both;"&gt;&lt;/div&gt;&lt;img src="http://blogs.msdn.com/aggbug.aspx?PostID=593746" width="1" height="1"&gt;</description></item></channel></rss>