Re: set-file-extended-attributes and backups

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 21 Dec 2012 08:00:01 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: Romain Francoise <romain@orebokech.com>
> 
> On 12/21/12 06:53, Eli Zaretskii wrote:
> > I think this problem is not Windows-specific.  So I'm asking here:
> > does it make sense to fail backup-buffer and backup-buffer-copy just
> > because set-file-extended-attributes fails?  I think we should ignore
> > such errors
> 
> On systems where ACLs can deny access to files, failing to
> copy an ACL can mean that the copy has more permissions
> than the original, no?

Yes, I think so, at least when we are not backing up by renaming.

> Wouldn't that be a security problem?

Maybe.  But Emacs does the same on platforms where ACLs are not
accessible to Emacs, so if there's a security problem, we already have
it, I think.

> As I understand it, Windows ACLs can deny access, just as
> Posix ACLs can, so this issue is relevant on Windows too.

Yes, Windows ACLs can deny access, and yes, it is relevant.

> The recently-added ACL code has some security holes in
> this area, doesn't it?  It's copying file mode separately
> from copying ACLs.  Surely the code should just copy ACLs,
> as there's a race condition now, where the file is
> temporarily exposed between the times the mode and the
> ACLs are copied.

How about if it tried to copy ACLs, and if that failed, attempted to
copy the file modes?  That would DTRT if possible, and fall back on
the pre-ACL method if not.