unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Signaling an error while saving files due to file-extended-attributes
@ 2020-09-29 15:29 Eli Zaretskii
  2020-09-29 16:58 ` Paul Eggert
  0 siblings, 1 reply; 5+ messages in thread
From: Eli Zaretskii @ 2020-09-29 15:29 UTC (permalink / raw)
  To: Paul Eggert; +Cc: emacs-devel

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?



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Signaling an error while saving files due to file-extended-attributes
  2020-09-29 15:29 Signaling an error while saving files due to file-extended-attributes Eli Zaretskii
@ 2020-09-29 16:58 ` Paul Eggert
  2020-09-29 17:14   ` Eli Zaretskii
  0 siblings, 1 reply; 5+ messages in thread
From: Paul Eggert @ 2020-09-29 16:58 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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.




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Signaling an error while saving files due to file-extended-attributes
  2020-09-29 16:58 ` Paul Eggert
@ 2020-09-29 17:14   ` Eli Zaretskii
  2020-09-29 20:23     ` Paul Eggert
  0 siblings, 1 reply; 5+ messages in thread
From: Eli Zaretskii @ 2020-09-29 17:14 UTC (permalink / raw)
  To: Paul Eggert; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Signaling an error while saving files due to file-extended-attributes
  2020-09-29 17:14   ` Eli Zaretskii
@ 2020-09-29 20:23     ` Paul Eggert
  2020-09-30 14:43       ` Eli Zaretskii
  0 siblings, 1 reply; 5+ messages in thread
From: Paul Eggert @ 2020-09-29 20:23 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Signaling an error while saving files due to file-extended-attributes
  2020-09-29 20:23     ` Paul Eggert
@ 2020-09-30 14:43       ` Eli Zaretskii
  0 siblings, 0 replies; 5+ messages in thread
From: Eli Zaretskii @ 2020-09-30 14:43 UTC (permalink / raw)
  To: Paul Eggert; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-09-30 14:43 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-09-29 15:29 Signaling an error while saving files due to file-extended-attributes Eli Zaretskii
2020-09-29 16:58 ` Paul Eggert
2020-09-29 17:14   ` Eli Zaretskii
2020-09-29 20:23     ` Paul Eggert
2020-09-30 14:43       ` Eli Zaretskii

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).