GNU bug report logs - #44631
28.0.50; Byte compilation fails if destination file is a mount point

Previous Next

Full log

Message #14 received at 44631 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 44631 <at> debbugs.gnu.org
Subject: Re: bug#44631: 28.0.50; Byte compilation fails if destination file
 is a mount point
Date: Tue, 24 Nov 2020 07:16:24 +0100

Philipp Stephani <p.stephani2 <at> gmail.com> writes:

> I've been experimenting with creating a sandbox for Emacs using
> https://developers.google.com/sandboxed-api/. That works by (a)
> installing a Linux kernel syscall filter to limit the allowed
> syscalls, and (b) enabling user and mount namespaces. Using the mount
> namespaces, the sandbox can be restricted exactly to the files that
> Emacs needs to access. In the case of byte compilation, it needs to
> write exactly one file, the byte-compiled output, so it's possible to
> mount exactly that file. This bug makes this approach impossible.

Hm, interesting...

>> > Nevertheless, byte-compile-file could
>> > fall back to a direct write-region without temporary file + rename, or
>> > rename-file could fall back to copy + remove on EBUSY (like EXDEV).
>>
>> Hm...  the latter sounds like an easy fix, but aren't there more commond
>> cases where you get EBUSY where copy + remove would fail, too?
>
> Probably, but I guess the situation wouldn't become worse, as
> presumably these cases already fail today.

No, I can't think of any cases where this would lead to a worse result
than the current situation, but it's somewhat scary making a low-level
general change like this in `rename-file' -- I have no idea whether
EBUSY is used for other oddball failure cases like this.

Making the change in byte-compile-file sounds safer, but would require
more work.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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