Re: Signaling an error while saving files due to file-extended-attributes

[Eli Zaretskii <eliz@gnu.org>]

> Cc: emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 29 Sep 2020 09:58:19 -0700
> 
> On 9/29/20 8:29 AM, Eli Zaretskii wrote:
> > This is probably OK for the primitives that access the extended
> > attributes, but what about their calls during saving a buffer to its
> > file?  Signaling an error there effectively prevents users from saving
> > their edits in such cases, which IMO makes little sense.
> 
> The same thing happens if file-modes signals an error, which can happen if there 
> is an I/O error, or if someone else has removed the file while Emacs is running, 
> or whatever. Surely a file-extended-attributes error should be treated like a 
> file-modes error?

In principle, yes.  However, IME file-extended-attributes is more
prone to such problems because all kinds of unusual methods of
mounting a volume tend to have incomplete or missing support for the
extended attributes.  The result is a perceived regression wrt Emacs
26, quite serious from the user's POV, given the fact that we don't
have a way of disabling the copying of file-extended-attributes.

> The worry about ignoring errors is that the user will create a file that 
> contains sensitive data but which has too-generous access permissions because we 
> couldn't determine permissions.

So maybe some kind of warning and confirmation request is in order?
And perhaps a way of disabling the extended attributes for files under
directories from some list?

> One possible solution would be to use the stingiest permissions on the backup 
> file if we cannot determine the permissions of the original. This would be mode 
> 700 (with no setuid etc. bits) for POSIX modes; I don't know offhand what it 
> would be for ACLs or for SELinux.

That's the problem: I don't think the equivalent of 700 exists for the
extended attributes.