GNU bug report logs - #865
23.0.60; The directory is unsafe today

Previous Next

Package: emacs;

Reported by: "Lennart Borgman (gmail)" <lennart.borgman <at> gmail.com>

Date: Tue, 2 Sep 2008 16:10:05 UTC

Severity: normal

Merged with 3281, 4197, 8787

Found in version 23.3

Full log


Message #550 received at 865 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Lennart Borgman (gmail)" <lennart.borgman <at> gmail.com>
To: Francis Litterio <flitterio <at> gmail.com>, 865 <at> debbugs.gnu.org
Subject: Re: bug#865: 23.0.60; The directory is unsafe today
Date: Sat, 06 Sep 2008 19:41:37 +0200
Francis Litterio wrote:
> Eli Zaretskii wrote:
> 
>>> From: Stefan Monnier
> 
>>> But I'd argue that having the umask (aka default-file-modes) set to
>>> #o700 could be used as a tell-tale sign, so it sounds to me like it
>>> might be doable by adding w32 C code without any C-level changes.
>> So you are saying we should assume that when umask has its two lower
>> mode bits set to zero, the intent is to create a private file
>> accessible only by the user who runs Emacs?  I don't like such
>> assumptions, but if I'm the only one, so be it.
> 
> Overloading the semantics of a subset of the bits in the umask seems
> prone to confusion.  Why not create a new w32-... variable to encode
> those semantics?


Unfortunately they are already overloaded on w32. I think the best
remedy would be to just remove that on w32. New primitives are needed if
we really want to handle security from within Emacs.

I am not sure it is good to do that, but if you really want to handle
security it must of course be carefully done.

For the current problem a work around using a special function in
server-ensure-safe-dir for OS:es that uses ACLs for security control
would be the best in my opinion.





This bug report was last modified 7 years and 236 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.