bug#4197: 23.1; error when try to run `server-start': directory .emacs.d/server is unsafe

bug#4197: 23.1; error when try to run `server-start': directory .emacs.d/server is unsafe

[Drew Adams]

In the Emacs bin directory:
 
.\cmdproxy.exe
 
At the cmd prompt:
 
.\runemacs.exe -Q
 
In *scratch* buffer, eval this: (server-start)
 
Debugger entered--Lisp error: (error "The directory c:/.emacs.d/server is
unsafe")
  signal(error ("The directory c:/.emacs.d/server is unsafe"))
  error("The directory %s is unsafe" "c:/.emacs.d/server")
  server-ensure-safe-dir("c:/.emacs.d/server/")
  server-start()
  eval((server-start))
  eval-last-sexp-1(nil)
  eval-last-sexp(nil)
  call-interactively(eval-last-sexp nil nil)
 

In GNU Emacs 23.1.1 (i386-mingw-nt5.1.2600)
 of 2009-07-29 on SOFT-MJASON
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4)'
 

bug#4197: 23.1; error when try to run `server-start': directory .emacs.d/server is unsafe

[Eli Zaretskii]

merge 865 4197

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Tue, 18 Aug 2009 20:25:25 -0700
> Cc: 
> 
> In the Emacs bin directory:
>  
> .\cmdproxy.exe
>  
> At the cmd prompt:
>  
> .\runemacs.exe -Q
>  
> In *scratch* buffer, eval this: (server-start)
>  
> Debugger entered--Lisp error: (error "The directory c:/.emacs.d/server is
> unsafe")
>   signal(error ("The directory c:/.emacs.d/server is unsafe"))
>   error("The directory %s is unsafe" "c:/.emacs.d/server")
>   server-ensure-safe-dir("c:/.emacs.d/server/")
>   server-start()
>   eval((server-start))
>   eval-last-sexp-1(nil)
>   eval-last-sexp(nil)
>   call-interactively(eval-last-sexp nil nil)

I think this is the same as bug #865; merged.

What do the following three expression evaluate to, in the Emacs session
that signals this error?

  (user-uid)

  (file-attributes "c:/.emacs.d/server/" 'integer)

  (file-attributes "c:/.emacs.d/server/" 'string)

Finally, does it help to set w32-get-true-file-attributes to nil?

bug#4197: 23.1; error when try to run `server-start': directory .emacs.d/server is unsafe

[Drew Adams]

> I think this is the same as bug #865; merged.
> What do the following three expression evaluate to, in the 
> Emacs session that signals this error?
> 
>   (user-uid)

19729

>   (file-attributes "c:/.emacs.d/server/" 'integer)

(t 1 0 0 (18967 40688) (18657 6612) (18657 6611) 0
 "drwxrwxrwx" t (572354 . 24704) 240391127)

>   (file-attributes "c:/.emacs.d/server/" 'string)

(t 1 "Everyone" "Everyone" (18967 40688) (18657 6612)
 (18657 6611) 0 "drwxrwxrwx" t (572354 . 24704) 240391127)

> Finally, does it help to set w32-get-true-file-attributes to nil?

Yes! Thanks for your prompt reply.

If this is the same as #865, then I guess it is pretty old. Dunno whether my
laptop configuration (Windows XP SP3, with FAT32 drive) is atypical or not.

If not, until the bug is fixed you might consider changing the default value to
nil, since this stops users with a similar config from using emacsclient at all
(out of the box, emacs -Q). Unless they know about the workaround, that is.
Without your help, I never would have guessed it. I don't even understand the
error message, "The directory is unsafe" - maybe that message could refer me to
a manual section explaining unsafe directories?

Anyway, thanks for the workaround.

bug#4197: 23.1; error when try to run `server-start': directory .emacs.d/server is unsafe

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: "'Lennart Borgman'" <lennart.borgman@gmail.com>
> Date: Fri, 21 Aug 2009 07:30:11 -0700
> 
> > I think this is the same as bug #865; merged.
> > What do the following three expression evaluate to, in the 
> > Emacs session that signals this error?
> > 
> >   (user-uid)
> 
> 19729
> 
> >   (file-attributes "c:/.emacs.d/server/" 'integer)
> 
> (t 1 0 0 (18967 40688) (18657 6612) (18657 6611) 0
>  "drwxrwxrwx" t (572354 . 24704) 240391127)
> 
> >   (file-attributes "c:/.emacs.d/server/" 'string)
> 
> (t 1 "Everyone" "Everyone" (18967 40688) (18657 6612)
>  (18657 6611) 0 "drwxrwxrwx" t (572354 . 24704) 240391127)

Ah! a FAT32 filesystem!

> If this is the same as #865, then I guess it is pretty old.

It's been on my TODO forever to fix this, and I even wrote some code
towards that goal.  But the problem is not easy to crack, since
Windows sometimes attribute files not to the user who created them,
but to the Administrators group instead, and that doesn't go well with
the Posix-at-heart code which triggers this error.  Eventually, we
will need to add more code to file-attributes and to make-directory,
so that Emacs could create really private directories on Windows.

> Dunno whether my
> laptop configuration (Windows XP SP3, with FAT32 drive) is atypical or not.

It's the FAT32 thing that trips you.  It doesn't support Windows
native security features, so every file is attributed to Everyone
(user-id of zero).  emacsclient wants to be sure the directory where
it places its socket file cannot be written to by any other user, but
the fact its owner is Everyone, not you, tells emacsclient that the
directory isn't private.

Can you perhaps convert the drive to NTFS?

> If not, until the bug is fixed you might consider changing the default value to
> nil, since this stops users with a similar config from using emacsclient at all
> (out of the box, emacs -Q). Unless they know about the workaround, that is.

We never heard about the problem until now, since Emacs 23 was
released (the original bug was reported long ago, when Emacs 23 was
still in development).  So it seems the problem is not too frequent:
the number of people who use emacsclient on a FAT32 volume or that
belong to the local Administrators group is apparently low enough for
this gotcha not to hit too frequently.

> Without your help, I never would have guessed it. I don't even understand the
> error message, "The directory is unsafe" - maybe that message could refer me to
> a manual section explaining unsafe directories?

I will add this to PROBLEMS, and look into modifying the message.  I
think the message text is not very clear even on Unix.  Thanks for
pointing this out.

bug#4197: 23.1; error when try to run `server-start': directory .emacs.d/server is unsafe

[Drew Adams]

> Ah! a FAT32 filesystem!

You sound surprised. That's really not uncommon. ;-) Might even be more common
than NTFS.

> > If this is the same as #865, then I guess it is pretty old.
> 
> It's been on my TODO forever to fix this, and I even wrote some code
> towards that goal.  But the problem is not easy to crack, since
> Windows sometimes attribute files not to the user who created them,
> but to the Administrators group instead, and that doesn't go well with
> the Posix-at-heart code which triggers this error.  Eventually, we
> will need to add more code to file-attributes and to make-directory,
> so that Emacs could create really private directories on Windows.
> 
> > Dunno whether my laptop configuration (Windows XP SP3,
> > with FAT32 drive) is atypical or not.
> 
> It's the FAT32 thing that trips you.  It doesn't support Windows
> native security features, so every file is attributed to Everyone
> (user-id of zero).

OK, but FAT32 is very common. I wonder about the default for the variable being
non-nil, even after the bug is fixed, but especially before then.

> emacsclient wants to be sure the directory where
> it places its socket file cannot be written to by any other user, but
> the fact its owner is Everyone, not you, tells emacsclient that the
> directory isn't private.
> 
> Can you perhaps convert the drive to NTFS?

No. Is it a joke?

FWIW, when I had a personal machine, I used NTFS. This is not my personal
laptop. This is the standard issue for my company. My guess is that others,
beyond my company, are in the same boat. The answer is not to ask them to
convert their disk drives.

I think Emacs should be able to coexist and behave nicely with FAT32 - don't
you? If some extra Emacs features are not available for FAT32, so be it, but
using FAT32 should not prevent one from using Emacs (e.g. emacsclient).

> > If not, until the bug is fixed you might consider changing 
> > the default value to nil, since this stops users with a
> > similar config from using emacsclient at all (out of the box,
> > emacs -Q). Unless they know about the workaround, that is.
> 
> We never heard about the problem until now, since Emacs 23 was
> released (the original bug was reported long ago, when Emacs 23 was
> still in development).  So it seems the problem is not too frequent:
> the number of people who use emacsclient on a FAT32 volume or that
> belong to the local Administrators group is apparently low enough for
> this gotcha not to hit too frequently.

I wouldn't bet on that at all.

* Emacs 23 was just released. I never tried to use emacsclient - I did so in
order to follow a bug report (for my code, and unrelated to emacsclient, as it
turns out).

* FAT32 is very common.

* AFAIK, every user in my company belongs to the local Administrators group for
his/her machine (e.g. laptop), so that s?he can easily install stuff etc. Other
organizations might have similar policies.

It doesn't make sense to make the default behavior dependent on assuming that
users do not have FAT32 and are not in the local Administrators group. IMO.
That's a crippling assumption.

> > Without your help, I never would have guessed it. I don't 
> > even understand the error message, "The directory is unsafe"
> > - maybe that message could refer me to
> > a manual section explaining unsafe directories?
> 
> I will add this to PROBLEMS, and look into modifying the message.  I
> think the message text is not very clear even on Unix.  Thanks for
> pointing this out.

Beyond the message text, what does it mean? Where is this notion of "unsafe
directory" documented in the manuals?

I see in the Emacs manual a discussion of unsafe variables, but not of unsafe
directories. I see in the Elisp manual mention of unsafe variables and unsafe
functions, but nothing about unsafe directories.

I think this should be explained in the manual(s) - we shouldn't simply improve
the message (though that too should be done). It is especially important to
document things that concern safety (if this really does).

Thx - Drew

bug#4197: 23.1; error when try to run `server-start': directory .emacs.d/server is unsafe

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <4197@emacsbugs.donarmstrong.com>, <lennart.borgman@gmail.com>
> Date: Fri, 21 Aug 2009 11:12:16 -0700
> 
> OK, but FAT32 is very common. I wonder about the default for the variable being
> non-nil, even after the bug is fixed, but especially before then.

The variable does more than just influence server.el.  It makes
file-attributes more accurate, which has its own benefits, most
prominently in Dired.

> > Can you perhaps convert the drive to NTFS?
> 
> No. Is it a joke?

No, I tried to help you work around the problem (and get a better
filesystem while at that).

> This is not my personal laptop. This is the standard issue for my
> company.

I couldn't know that, could I?

> I think Emacs should be able to coexist and behave nicely with FAT32 - don't
> you?

I do, and it does -- mostly.

> It doesn't make sense to make the default behavior dependent on assuming that
> users do not have FAT32 and are not in the local Administrators group. IMO.
> That's a crippling assumption.

The code in server.el assumes a Posix filesystem.  We are trying to
get it to work nicely on Windows, when some of these assumptions don't
hold.  IOW, no one specifically assumed users do not have FAT32.

> Beyond the message text, what does it mean? Where is this notion of "unsafe
> directory" documented in the manuals?

It is a more or less common knowledge in the Posix world.  But I do
agree that the message text should be more self-explanatory.

> I think this should be explained in the manual(s) - we shouldn't simply improve
> the message (though that too should be done). It is especially important to
> document things that concern safety (if this really does).

If the message is explicit enough, it will explain itself.

bug#4197: 23.1; error when try to run `server-start': directory .emacs.d/server is unsafe

[Drew Adams]

> > OK, but FAT32 is very common. I wonder about the default 
> > for the variable being non-nil, even after the bug is fixed,
> > but especially before then.
> 
> The variable does more than just influence server.el.  It makes
> file-attributes more accurate, which has its own benefits, most
> prominently in Dired.

I don't doubt that. I know that NTFS offers a good deal more in terms of file
security possibilities than does FAT32.

But if the default value of the variable is inappropriate for some platform
(disk format), then it should be changed - at least on that platform.

Can you not test for this (e.g. using code similar to what you asked me to
evaluate to test this), and set the default value accordingly?

Or perhaps (since a user can have multiple drives with different formats) the
code that uses this option should check whether a non-nil value makes sense for
the drive in question, before simply proceeding as it does today.

Anyway, I'm unfamilar with the implementation, and I'm no expert on this
subject, so I'll leave the bug fix to others. From a user point of view,
something needs to be fixed here; that's all.

> > > Can you perhaps convert the drive to NTFS?
> > 
> > No. Is it a joke?
> 
> No, I tried to help you work around the problem (and get a better
> filesystem while at that).
> 
> > This is not my personal laptop. This is the standard issue for my
> > company.
> 
> I couldn't know that, could I?

No, I didn't say that you could have or should have. You asked, and I told you;
that's all.

I'm letting you know that (a) no, unfortunately, I cannot change the drive
format, (b) changing the drive format cannot be the general answer to the
problem, even if it might help some users sometimes, and (c) this is a
widespread policy, in at least some organizations, so this likely does not
represent an isolated case, even if it's the first reported case.

> > I think Emacs should be able to coexist and behave nicely 
> > with FAT32 - don't you?
> 
> I do, and it does -- mostly.

Clearly I meant including in this regard - the question at hand.

There is no reason to be defensive (if you are doing that) about a bug. I can
understand that the bug might be difficult to fix in the best way, and that
takes time.

In the meantime, something can perhaps be done as a preventive measure. If the
drive format for Windows could be tested, that might be a solution. If not, if
nothing else can be done in the immediate, then I would suggest changing the
default for at least all Windows users to nil. 

IOW, better to forego the bells and whistles while waiting for a real fix, and
to at least let users use emacsclient without customizing. In this meantime
period, the doc can let Windows users know that if they happen to have NTFS
storage, then they can get more bells and whistles by changing the value to
non-nil.

I can understand that a developer wants to show off new, enhanced behavior, but
that shouldn't be the default if it leads to fundamental problems. Users who
have NTFS can easily customize to get the enhanced behavior.

> > It doesn't make sense to make the default behavior 
> > dependent on assuming that users do not have FAT32 and are
> > not in the local Administrators group. IMO.
> > That's a crippling assumption.
> 
> The code in server.el assumes a Posix filesystem.  We are trying to
> get it to work nicely on Windows, when some of these assumptions don't
> hold.

I understand. Good.

> IOW, no one specifically assumed users do not have FAT32.

I didn't think so. I imagine that it was just an oversight (implicit
assumption).

> > Beyond the message text, what does it mean? Where is this 
> > notion of "unsafe directory" documented in the manuals?
> 
> It is a more or less common knowledge in the Posix world.  But I do
> agree that the message text should be more self-explanatory.

The world of Emacs users is not identical to the Posix world. Emacs doc should
not assume that Emacs users have all the "common knowledge" of the Posix world.

This needs to be documented, beyond the error message. Users need to know how to
use this, including, at least for now, how to use it with FAT32 vs NTFS.

> > I think this should be explained in the manual(s) - we 
> > shouldn't simply improve the message (though that too should
> > be done). It is especially important to
> > document things that concern safety (if this really does).
> 
> If the message is explicit enough, it will explain itself.

The message explaining itself will be corrected when the message is corrected.

My concern is beyond the message: Providing the essential info in this bug
report to users. Thx.

bug#4197: 23.1; error when try to run `server-start': directory .emacs.d/server is unsafe

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <4197@emacsbugs.donarmstrong.com>, <lennart.borgman@gmail.com>
> Date: Fri, 21 Aug 2009 11:55:27 -0700
> 
> But if the default value of the variable is inappropriate for some platform
> (disk format), then it should be changed - at least on that platform.
> 
> Can you not test for this (e.g. using code similar to what you asked me to
> evaluate to test this), and set the default value accordingly?

I don't think we need to change the value of
w32-get-true-file-attributes on FAT32 volumes.  All we need is fix
server.el to not barf on FAT32 volumes.  I'll see what I can do.

> There is no reason to be defensive (if you are doing that) about a
> bug.

There's no need to become angry, either.

> I can understand that a developer wants to show off new, enhanced behavior, but
> that shouldn't be the default if it leads to fundamental problems.

This developer simply doesn't have enough time to fix everything right
away.  That is the only reason this bug is not yet fixed.  That, and
the fact that no one else beat me to it.  There's no show-off anywhere
in sight.

bug#4197: 23.1; error when try to run `server-start': directory .emacs.d/server is unsafe

[Drew Adams]

> I don't think we need to change the value of
> w32-get-true-file-attributes on FAT32 volumes.  All we need is fix
> server.el to not barf on FAT32 volumes.  I'll see what I can do.

OK, great.

> > There is no reason to be defensive (if you are doing that) about a
> > bug.
> 
> There's no need to become angry, either.

I'm not at all angry (if you meant me).

And I'm grateful that this will be fixed.

bug#4197: 23.1; error when try to run `server-start': directory .emacs.d/server is unsafe

[Stefan Monnier]

> I think Emacs should be able to coexist and behave nicely with FAT32 - don't

IIUC how Windows on FAT32 works, using emacsserver on such a system
means that any process running on this machine (from your own user or
any other user) can control your Emacs session.


        Stefan

bug#4197: 23.1; error when try to run `server-start': directory .emacs.d/server is unsafe

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 4197@emacsbugs.donarmstrong.com,  "'Eli Zaretskii'" <eliz@gnu.org>
> Date: Sat, 22 Aug 2009 00:49:03 -0400
> 
> > I think Emacs should be able to coexist and behave nicely with FAT32 - don't
> 
> IIUC how Windows on FAT32 works, using emacsserver on such a system
> means that any process running on this machine (from your own user or
> any other user) can control your Emacs session.

That's true.  There's no file security on FAT32 volumes.

I was thinking about displaying yes-or-no-p prompt with a warning to
that effect, but if the user consents, letting them to proceed.  Maybe
we should do that on Posix as well, instead of flatly refusing to run.

WDYT?

bug#4197: 23.1; error when try to run `server-start': directory .emacs.d/server is unsafe

[Jason Rumney]

Stefan Monnier wrote:
>> I think Emacs should be able to coexist and behave nicely with FAT32 - don't
>>     
>
> IIUC how Windows on FAT32 works, using emacsserver on such a system
> means that any process running on this machine (from your own user or
> any other user) can control your Emacs session.
>   

Yes. The security feature of emacsclient should probably be abstracted 
so that appropriate methods for the platform can be used.  Then on 
Windows (NT) we could use Security Descriptors directly without relying 
on the filesystem to be secure. Windows 95/98/ME would require a 
different solution, but I don't think it is worth expending any more 
effort than the Yes/No dialog that Eli suggests.

bug#4197: 23.1; error when try to run `server-start': directory .emacs.d/server is unsafe

[Eli Zaretskii]

> Date: Fri, 21 Aug 2009 23:35:58 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 4197@emacsbugs.donarmstrong.com
> 
> > From: "Drew Adams" <drew.adams@oracle.com>
> > Cc: <4197@emacsbugs.donarmstrong.com>, <lennart.borgman@gmail.com>
> > Date: Fri, 21 Aug 2009 11:55:27 -0700
> > 
> > But if the default value of the variable is inappropriate for some platform
> > (disk format), then it should be changed - at least on that platform.
> > 
> > Can you not test for this (e.g. using code similar to what you asked me to
> > evaluate to test this), and set the default value accordingly?
> 
> I don't think we need to change the value of
> w32-get-true-file-attributes on FAT32 volumes.  All we need is fix
> server.el to not barf on FAT32 volumes.  I'll see what I can do.

Can you please try the following patch to server.el?  It is checked in
on the release branch.

2009-08-22  Eli Zaretskii  <eliz@gnu.org>

	* server.el (server-ensure-safe-dir): Disable the security check
	for Windows.

Index: lisp/server.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/server.el,v
retrieving revision 1.192
diff -u -r1.192 server.el
--- lisp/server.el	10 Mar 2009 14:09:26 -0000	1.192
+++ lisp/server.el	22 Aug 2009 10:06:05 -0000
@@ -452,9 +452,10 @@
     (unless attrs
       (letf (((default-file-modes) ?\700)) (make-directory dir t))
       (setq attrs (file-attributes dir)))
-    ;; Check that it's safe for use.
-    (unless (and (eq t (car attrs)) (eql (nth 2 attrs) (user-uid))
-                 (or (eq system-type 'windows-nt)
+    ;; Check that it's safe for use.  Windows doesn't support
+    ;; Posix-style file security, so don't check there.
+    (unless (or (eq system-type 'windows-nt)
+		(and (eq t (car attrs)) (eql (nth 2 attrs) (user-uid))
                      (zerop (logand ?\077 (file-modes dir)))))
       (error "The directory %s is unsafe" dir))))
 

bug#4197: 23.1; error when try to run `server-start': directory .emacs.d/server is unsafe

[Eli Zaretskii]

> Date: Sat, 22 Aug 2009 17:53:15 +0800
> From: Jason Rumney <jasonr@f2s.com>
> Cc: 
> 
> Yes. The security feature of emacsclient should probably be abstracted 
> so that appropriate methods for the platform can be used.  Then on 
> Windows (NT) we could use Security Descriptors directly without relying 
> on the filesystem to be secure.

Sorry, I don't quite understand your suggestion.  NT file security
cannot be used on FAT32 volumes, even if the OS is of the NT family
(Windows 2000, XP, etc.).  So, if you meant to use the NT file
security as the back-end of the abstraction you propose, that back-end
will be inoperable on FAT32 volumes, even for Windows XP.

bug#4197: 23.1; error when try to run `server-start': directory .emacs.d/server is unsafe

[Jason Rumney]

Eli Zaretskii wrote:
> Sorry, I don't quite understand your suggestion.  NT file security
> cannot be used on FAT32 volumes, even if the OS is of the NT family
> (Windows 2000, XP, etc.).  So, if you meant to use the NT file
> security as the back-end of the abstraction you propose, that back-end
> will be inoperable on FAT32 volumes, even for Windows XP.
>   
No, I mean instead of using the file system, which is only secure if it 
is NTFS, use Access Tokens, or switch to using Named Pipes instead of a 
TCP socket, so that a Security Descriptor can be attached to it.

bug#4197: 23.1; error when try to run `server-start': directory .emacs.d/server is unsafe

[Lennart Borgman]

On Sat, Aug 22, 2009 at 6:59 PM, Jason Rumney<jasonr@gnu.org> wrote:
> Eli Zaretskii wrote:
>>
>> Sorry, I don't quite understand your suggestion.  NT file security
>> cannot be used on FAT32 volumes, even if the OS is of the NT family
>> (Windows 2000, XP, etc.).  So, if you meant to use the NT file
>> security as the back-end of the abstraction you propose, that back-end
>> will be inoperable on FAT32 volumes, even for Windows XP.
>>
>
> No, I mean instead of using the file system, which is only secure if it is
> NTFS, use Access Tokens, or switch to using Named Pipes instead of a TCP
> socket, so that a Security Descriptor can be attached to it.

Didn't someone write an implementation of emacsclient on w32 using
Named Pipes? Would not that also be preferrable to avoid problems with
firewalls on the local computer?

But what about connecting to servers on other hosts? Or is that
perhaps not something that can be done? Or can that possibility be
kept open by also allowing for using TCP on w32?

bug#4197: 23.1; error when try to run `server-start': directory .emacs.d/server is unsafe

[Stefan Monnier]

> Didn't someone write an implementation of emacsclient on w32 using
> Named Pipes? Would not that also be preferrable to avoid problems with
> firewalls on the local computer?

The generic code works well, so we shouldn't expend efforts on
supporting another protocol.  If we can support Unix sockets under w32,
that would be an acceptable alternative.  But in any case, the check
made by emacsserver is meaningless in an unsecure system such as
w32-on-fat32, so we should just skip it in such a circumstance.


        Stefan

bug#4197: 23.1; error when try to run `server-start': directory .emacs.d/server is unsafe

[Stefan Monnier]

>> > I think Emacs should be able to coexist and behave nicely with
>> > FAT32 - don't
>> IIUC how Windows on FAT32 works, using emacsserver on such a system
>> means that any process running on this machine (from your own user or
>> any other user) can control your Emacs session.
> That's true.  There's no file security on FAT32 volumes.
> I was thinking about displaying yes-or-no-p prompt with a warning to
> that effect, but if the user consents, letting them to proceed.  Maybe
> we should do that on Posix as well, instead of flatly refusing to run.

I don't see a need for a prompt under POSIX.
For a FAT32 system under w32, we probably don't need a prompt either (we
should just skip the test instead) either the user is aware of the
inherent insecurity of his system (in which case we can go on and ignore
the problem without prompting), or he's not, in which case a prompt will
just confuse him even more.


        Stefan

bug#4197: 23.1; error when try to run `server-start': directory .emacs.d/server is unsafe

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: drew.adams@oracle.com,  4197@emacsbugs.donarmstrong.com
> Date: Sat, 22 Aug 2009 21:57:49 -0400
> 
> For a FAT32 system under w32, we probably don't need a prompt either (we
> should just skip the test instead) either the user is aware of the
> inherent insecurity of his system (in which case we can go on and ignore
> the problem without prompting), or he's not, in which case a prompt will
> just confuse him even more.

The user might have more than one filesystem on her machine.  Telling
her that the one she uses for ~/.emacs_d is insecure might cause her
to change her configuration, I think.

bug#4197: 23.1; error when try to run `server-start': directory .emacs.d/server is unsafe

[Stefan Monnier]

>> For a FAT32 system under w32, we probably don't need a prompt either (we
>> should just skip the test instead) either the user is aware of the
>> inherent insecurity of his system (in which case we can go on and ignore
>> the problem without prompting), or he's not, in which case a prompt will
>> just confuse him even more.

> The user might have more than one filesystem on her machine.  Telling
> her that the one she uses for ~/.emacs_d is insecure might cause her
> to change her configuration, I think.

Could be.  But I don't think this slim hope warrants imposing a prompt
on all the other lusers.  A message should be sufficient.


        Stefan