unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Windows Emacs and "VirtualStore"
@ 2010-04-17 15:47 Lewis Perin
  2010-04-19 21:12 ` Lewis Perin
  0 siblings, 1 reply; 7+ messages in thread
From: Lewis Perin @ 2010-04-17 15:47 UTC (permalink / raw)
  To: emacs-devel

Hello, Emacs developers.  I recently posted a query to gnu.emacs.help
and was told my request would be more appropriately sent to this forum.
So I subscribed, and here I am.

I just finished a long period of confusion after upgrading my Windows
machine from XP to Windows 7.  (What I'm about to say does apply to
Vista as well as 7, by the way.)

I've been running Emacs as an unprivileged user, responsible citizen
that I am.  I ran into trouble configuring a program whose config data
lie within the "Program Files" tree.  What's new in Windows since XP is
that that tree is not to be edited without privilege, but I forgot about
that.  And, in Emacs, it looked for all the world as if my edits were
being applied where I thought they were going.  But the program was
behaving as if it had never run into the changes I'd made.

Eventually I ran into

  http://xahlee.org/UnixResource_dir/writ/windows_virtualstore.html

which explains that, under Vista or Windows 7, the changes I was making
were *silently* being written into shadow copies of the "real" files out
in what's called "VirtualStore" in recent MS jargon.  (I'm not going to
fulminate here about MS's decision to do things in this way - they won't
back down.)

Xah Lee suggests running Emacs as administrator, but I'd rather not have
an admin Emacs running perpetually.  My reading of this MS document

  http://msdn.microsoft.com/en-us/library/bb756929.aspx

is that the problem of the silent redirection of writes would go away
if Windows Emacs had an appropriate "manifest file" with a Requested
Execution Level of "asInvoker".  That way, the write should fail the way
it would under XP if the file were locked, say.

I would actually prefer it if Emacs would give the user a chance to try
to escalate privilege in the sudo-ish way many Windows apps now employ.
I'm guessing that would require some work in the guts of Emacs.

With my shaky understanding of Emacs internals, I'm really not sure how
feasible these suggestions are.  Can someone who does understand these
things please comment?

Thanks very much for your attention.

/Lew
---
Lew Perin / perin@acm.org
http://www.panix.com/~perin/babelcarp.html




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Windows Emacs and "VirtualStore"
  2010-04-17 15:47 Windows Emacs and "VirtualStore" Lewis Perin
@ 2010-04-19 21:12 ` Lewis Perin
  2010-04-19 23:54   ` Chad Brown
  2010-04-20 15:47   ` Chong Yidong
  0 siblings, 2 replies; 7+ messages in thread
From: Lewis Perin @ 2010-04-19 21:12 UTC (permalink / raw)
  To: emacs-devel

A couple of days ago I wrote that running Emacs as a non-privileged
user on Vista or Windows 7 leads to some files being written silently
to places in the file system other than where Emacs (and the user)
thinks they're going.

As far as I'm concerned, I've solved part of the problem, at least
until the next time I upgrade.  Now when Emacs tries to write to a
place in the filesystem it has no right to write to, the program finds
out and complains to the user.

The fix doesn't require a change to the code of emacs, only to a
resource linked into the program: the Windows manifest, which is a
small XML script.  The manifest in the 23.1 Windows Emacs I have does
only one thing: it declares Emacs's dependence on
"Microsoft.Windows.Common-Controls".  This needs to be augmented by
some XML verbiage that tells Windows that the program is aware of
VirtualStore and prefers not to use it.  Here's the manifest I'm
using:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32"
      name="Microsoft.Windows.Common-Controls"
                        version="6.0.0.0" processorArchitecture="X86"
                        publicKeyToken="6595b64144ccf1df"
                        language="*"/>
    </dependentAssembly>
  </dependency>
  <assemblyIdentity version="1.0.0.0" processorArchitecture="X86"
  name="emacs" type="win32"/>
  <description>Mighty Emacs</description>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="asInvoker"/>
      </requestedPrivileges>
    </security>
  </trustInfo>
</assembly>

Obviously, I'd love it if something like this script were accepted as
part of Windows Emacs.  But until then, it can be applied to the
binary using a tool like the free-as-in-beer ResHacker.

When I said the augmented manifest was *part* of the solution, I meant
that an ideal solution would allow the user to escalate privilege by
typing an admin password for an attempt to rewrite a file when the
first write failed.  I've no idea if this would be as simple as it
sounds.  Is there someone reading this who's in a position to comment?

/Lew
---
Lew Perin | perin@acm.org | http://www.panix.com/~perin/babelcarp.html




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Windows Emacs and "VirtualStore"
  2010-04-19 21:12 ` Lewis Perin
@ 2010-04-19 23:54   ` Chad Brown
  2010-04-20 14:44     ` Lewis Perin
  2010-04-20 15:47   ` Chong Yidong
  1 sibling, 1 reply; 7+ messages in thread
From: Chad Brown @ 2010-04-19 23:54 UTC (permalink / raw)
  To: perin; +Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 1125 bytes --]

On Apr 19, 2010, at 2:12 PM, Lewis Perin wrote:

> [..]
> 
> When I said the augmented manifest was *part* of the solution, I meant
> that an ideal solution would allow the user to escalate privilege by
> typing an admin password for an attempt to rewrite a file when the
> first write failed.  I've no idea if this would be as simple as it
> sounds.  Is there someone reading this who's in a position to comment?

Nice work.  

I have no first-hand knowledge, but I have seen some complaints about 
problems with such a system on the forum for a computer game that I 
played recently.  The upshot was basically ``the escalation system is very
finicky'' -- and came with advice to avoid it if possible.  That was perhaps
a month ago.

Unless someone can find some first-hand evidence, I think we're much better
off (practically speaking) using something like your manifest, rather than 
waiting for an escalation system to be added to Emacs.  It does strike me that 
this must be a relatively common problem, so perhaps some other open or free
software product will have some useful experience?

*Chad

[-- Attachment #2: Type: text/html, Size: 1674 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Windows Emacs and "VirtualStore"
  2010-04-19 23:54   ` Chad Brown
@ 2010-04-20 14:44     ` Lewis Perin
  0 siblings, 0 replies; 7+ messages in thread
From: Lewis Perin @ 2010-04-20 14:44 UTC (permalink / raw)
  To: Chad Brown; +Cc: emacs-devel

>From: Chad Brown <yandros@MIT.EDU>
>Date: Mon, 19 Apr 2010 16:54:46 -0700
>
>On Apr 19, 2010, at 2:12 PM, Lewis Perin wrote:
>
>> [..]
>> 
>> When I said the augmented manifest was *part* of the solution, I meant
>> that an ideal solution would allow the user to escalate privilege by
>> typing an admin password for an attempt to rewrite a file when the
>> first write failed.  I've no idea if this would be as simple as it
>> sounds.  Is there someone reading this who's in a position to comment?
>[...]
>Unless someone can find some first-hand evidence, I think we're much better
>off (practically speaking) using something like your manifest, rather than 
>waiting for an escalation system to be added to Emacs.  

Obviously I agree with you on that.

>It does strike me that this must be a relatively common problem, so
>perhaps some other open or free software product will have some
>useful experience?

Indeed that would be interesting to see.  Right now on my Windows 7
machine I can see that Firefox is running with virualization disabled,
just like my manifest-hacked Emacs.  So obviously Mozilla's done
something.  Ah, wait a sec - let's look at their manifest - it's
pretty similar to the one I inserted into Emacs, actually.

Of course, it's quite possible that people who see VirtualStore as a
problem are a small minority among Vista and W7 users: maybe most
people still run as admin.

/Lew
---
Lew Perin | perin@acm.org | http://www.panix.com/~perin/babelcarp.html




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Windows Emacs and "VirtualStore"
  2010-04-19 21:12 ` Lewis Perin
  2010-04-19 23:54   ` Chad Brown
@ 2010-04-20 15:47   ` Chong Yidong
  2010-04-20 16:26     ` Lewis Perin
  1 sibling, 1 reply; 7+ messages in thread
From: Chong Yidong @ 2010-04-20 15:47 UTC (permalink / raw)
  To: perin; +Cc: emacs-devel

Lewis Perin <perin@panix.com> writes:

> The manifest in the 23.1 Windows Emacs I have does only one thing: it
> declares Emacs's dependence on "Microsoft.Windows.Common-Controls".
> This needs to be augmented by some XML verbiage that tells Windows
> that the program is aware of VirtualStore and prefers not to use it.

Thanks.  I've checked this intro the bzr trunk.




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Windows Emacs and "VirtualStore"
  2010-04-20 15:47   ` Chong Yidong
@ 2010-04-20 16:26     ` Lewis Perin
  2010-04-20 17:45       ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Lewis Perin @ 2010-04-20 16:26 UTC (permalink / raw)
  To: Chong Yidong; +Cc: emacs-devel

>From: Chong Yidong <cyd@stupidchicken.com>
>Date: Tue, 20 Apr 2010 11:47:48 -0400
>
>Lewis Perin <perin@panix.com> writes:
>
>> The manifest in the 23.1 Windows Emacs I have does only one thing: it
>> declares Emacs's dependence on "Microsoft.Windows.Common-Controls".
>> This needs to be augmented by some XML verbiage that tells Windows
>> that the program is aware of VirtualStore and prefers not to use it.
>
>Thanks.  I've checked this intro the bzr trunk.

哪里!  Thank *you* for doing this quickly.

Would it be presumptuous to ask you if there's much chance of the file
saving logic being changed so privilege escalation for the save
becomes possible for Windows?

/Lew
---
Lew Perin | perin@acm.org | http://www.panix.com/~perin/babelcarp.html




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Windows Emacs and "VirtualStore"
  2010-04-20 16:26     ` Lewis Perin
@ 2010-04-20 17:45       ` Eli Zaretskii
  0 siblings, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2010-04-20 17:45 UTC (permalink / raw)
  To: perin; +Cc: cyd, emacs-devel

> From: Lewis Perin <perin@panix.com>
> Date: Tue, 20 Apr 2010 12:26:53 -0400 (EDT)
> Cc: emacs-devel@gnu.org
> 
> Would it be presumptuous to ask you if there's much chance of the file
> saving logic being changed so privilege escalation for the save
> becomes possible for Windows?

It's certainly possible, if someone codes such a solution and submits
it for inclusion.




^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2010-04-20 17:45 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-04-17 15:47 Windows Emacs and "VirtualStore" Lewis Perin
2010-04-19 21:12 ` Lewis Perin
2010-04-19 23:54   ` Chad Brown
2010-04-20 14:44     ` Lewis Perin
2010-04-20 15:47   ` Chong Yidong
2010-04-20 16:26     ` Lewis Perin
2010-04-20 17:45       ` Eli Zaretskii

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).