Tatsuya Kinoshita writes:
> On 2023-02-20 at 20:22 +, Andrea Corallo wrote:
>> I've installed 5d0b45cd67b on emacs-29 in order to use always
>> `make-temp-file'.
>
> Please be careful with the difference between make-temp-file-internal
> and make-temp-file.
>
>> +++ b/lisp/emacs-lisp/comp.el
On Mon, Feb 20, 2023, 4:34 PM Stefan Monnier
wrote:
> > Just to be clear, this condition should be checked before emacs is
> > willing to use the temporary directory in question. No unprivileged
> > user should be able to overwrite a directory entry the uid of the
> > emacs process creates at an
On 2023-02-20 at 20:22 +, Andrea Corallo wrote:
> I've installed 5d0b45cd67b on emacs-29 in order to use always
> `make-temp-file'.
Please be careful with the difference between make-temp-file-internal
and make-temp-file.
> +++ b/lisp/emacs-lisp/comp.el
> (expand-file-name
> -
> Just to be clear, this condition should be checked before emacs is
> willing to use the temporary directory in question. No unprivileged
> user should be able to overwrite a directory entry the uid of the
> emacs process creates at any point in the path to the temporary file.
AFAIK we usually c
On Mon, Feb 20, 2023 at 11:02 AM Stefan Monnier
wrote:
> > So I guess one could remove the file after the first creation and make
> > it a link pointing to some other file waiting for libgccjit to do
> > its write.
>
> "One" as in "an attacker"? In `/tmp` an attacker should not be able to
> do th
Eli Zaretskii writes:
>> From: Andrea Corallo
>> Cc: monn...@iro.umontreal.ca, t...@debian.org, emacs-de...@gnu.org,
>> spwhit...@spwhitton.name, 1021...@bugs.debian.org
>> Date: Mon, 20 Feb 2023 15:42:08 +
>>
>> > You mean, from master to emacs-29, I guess?
>>
>> Yes
>>
>> > What wa
Stefan Monnier writes:
>> Before e6043641d30 the file was created by Fmake_temp_file_internal and
>> afterwards overwritten by libgccjit.
>
> Yes, that was good.
>
>> So I guess one could remove the file after the first creation and make
>> it a link pointing to some other file waiting for libgcc
> From: Andrea Corallo
> Cc: monn...@iro.umontreal.ca, t...@debian.org, emacs-de...@gnu.org,
> spwhit...@spwhitton.name, 1021...@bugs.debian.org
> Date: Mon, 20 Feb 2023 15:42:08 +
>
> > You mean, from master to emacs-29, I guess?
>
> Yes
>
> > What was the motivation for that change?
Stefan Monnier writes:
>>> `make-temp-name` uses `O_EXCL | O_CREAT` so as to close the race
>>> condition: if someone predicated the filename, we detect it atomically
>>> and we try again.
>>>
>>> You might like to check
>>>
>>>
>>> https://wiki.sei.cmu.edu/confluence/display/c/FIO21-C.+Do+n
> Before e6043641d30 the file was created by Fmake_temp_file_internal and
> afterwards overwritten by libgccjit.
Yes, that was good.
> So I guess one could remove the file after the first creation and make
> it a link pointing to some other file waiting for libgccjit to do
> its write.
"One" as
Eli Zaretskii writes:
>> From: Andrea Corallo
>> Cc: Tatsuya Kinoshita , emacs-de...@gnu.org,
>> spwhit...@spwhitton.name, 1021...@bugs.debian.org, Eli Zaretskii
>>
>> Date: Mon, 20 Feb 2023 09:03:34 +
>>
>> OTOH on a slightly differnt subject and in light of this, I think we
>> shoul
>> `make-temp-name` uses `O_EXCL | O_CREAT` so as to close the race
>> condition: if someone predicated the filename, we detect it atomically
>> and we try again.
>>
>> You might like to check
>>
>>
>> https://wiki.sei.cmu.edu/confluence/display/c/FIO21-C.+Do+not+create+temporary+files+in+shar
> From: Andrea Corallo
> Cc: Tatsuya Kinoshita , emacs-de...@gnu.org,
> spwhit...@spwhitton.name, 1021...@bugs.debian.org, Eli Zaretskii
>
> Date: Mon, 20 Feb 2023 09:18:02 +
>
> Andrea Corallo writes:
>
> > Stefan Monnier writes:
> >
> >>> Shouldn't make-temp-file-internal return a
> From: Andrea Corallo
> Cc: Tatsuya Kinoshita , emacs-de...@gnu.org,
> spwhit...@spwhitton.name, 1021...@bugs.debian.org, Eli Zaretskii
>
> Date: Mon, 20 Feb 2023 09:03:34 +
>
> OTOH on a slightly differnt subject and in light of this, I think we
> should probably backport e6043641d30
Andrea Corallo writes:
> Stefan Monnier writes:
>
>>> Shouldn't make-temp-file-internal return a non predictable file name?
>>
>> Nope. It's less predictable but it's still predictable.
>>
>>> Otherwise what's the point of using make-temp-file in the first place if
>>> the temporary name is pre
Stefan Monnier writes:
>> Shouldn't make-temp-file-internal return a non predictable file name?
>
> Nope. It's less predictable but it's still predictable.
>
>> Otherwise what's the point of using make-temp-file in the first place if
>> the temporary name is predictable?
>
> `make-temp-name` use
On 2023-02-18 at 21:56 +, Andrea Corallo wrote:
> >> +(expand-file-name
> >> + (make-temp-file-internal (file-name-sans-extension
> >> rel-filename)
> >> + 0 ".eln" nil)
> >> + temporary-file-directory
> >
> > Hmm, it
> Shouldn't make-temp-file-internal return a non predictable file name?
Nope. It's less predictable but it's still predictable.
> Otherwise what's the point of using make-temp-file in the first place if
> the temporary name is predictable?
`make-temp-name` uses `O_EXCL | O_CREAT` so as to close
Tatsuya Kinoshita writes:
> On 2023-02-17 at 09:42 -0700, Sean Whitton wrote:
>> So: commit ce4a066ed1e fixes Debian bug #1021842 without the env var.
>
> On 2023-02-14 at 11:32 +, Andrea Corallo wrote:
>> Stefan Monnier writes:
>> > `temporary-file-directory' may point to a world-writable d
On 2023-02-17 at 09:42 -0700, Sean Whitton wrote:
> So: commit ce4a066ed1e fixes Debian bug #1021842 without the env var.
On 2023-02-14 at 11:32 +, Andrea Corallo wrote:
> Stefan Monnier writes:
> > `temporary-file-directory' may point to a world-writable directory, so
> > it's vulnerable to
> From: Sean Whitton
> Cc: Eli Zaretskii , aymeric.a...@yandex.com,
> monn...@iro.umontreal.ca, emacs-de...@gnu.org, la...@gnus.org,
> r...@defaultvalue.org
> Date: Fri, 17 Feb 2023 09:42:29 -0700
>
> > Otherwise you have to revert probably 654428b65ae and 2f28496d038 and
> > cherry pick i
Hello,
On Fri 17 Feb 2023 at 09:00AM GMT, Andrea Corallo wrote:
> can't you just test feature/inhibit-native-comp-cleanup directy? That
> would be the safest and simpler option IMO.
Not really -- Debian filters out a lot of the source tree due to
disagreements with the FSF regarding software fr
22 matches
Mail list logo
