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

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

[Eli Zaretskii]

Emacs 26 silently returned nil when file-acl or file-selinux-context
failed for a file.  Emacs 27 signals an error in that case (except
when the error returned by the low-level APIs are one of a small set
of errors that are taken as evidence that extended attributes are not
supported for the file).

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.

So how about wrapping the call to file-extended-attributes in
backup-buffer with '(ignore-error file-error ...)' ?  Are there any
potential problems with that in the context of saving a buffer?

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

[Paul Eggert]

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?

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.

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. Emacs should warn the user if it does this, 
presumably.

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

[Eli Zaretskii]

> 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.

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

[Paul Eggert]

On 9/29/20 10:14 AM, Eli Zaretskii wrote:
> 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?

A warning and confirmation request would be fine, I'd think. For completeness it 
should apply to both the less-problematic file-modes and the more-problematic 
file-extended-attributes.  A programmatic way should also be OK, though we would 
need to warn people against doing it casually as it can botch security.

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

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 29 Sep 2020 13:23:03 -0700
> 
> On 9/29/20 10:14 AM, Eli Zaretskii wrote:
> > 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?
> 
> A warning and confirmation request would be fine, I'd think. For completeness it 
> should apply to both the less-problematic file-modes and the more-problematic 
> file-extended-attributes.  A programmatic way should also be OK, though we would 
> need to warn people against doing it casually as it can botch security.

OK, I filed a feature request bug report about this.